In The Wizard of Oz, the Wizard tried to deceive Dorothy and her friends by issuing the stern warning, "Pay no attention to that man behind the curtain." When Toto opened the curtain, Dorothy's group understood the source of the Wizard's power and could use it to obtain their true desires which, unknown to them, were in their grasp all along.
AS/400 subsystems are also hidden behind a curtain-one of confusion and poor documentation. Subsystems are powerful work management tools that are often ignored because they are perceived as being difficult to understand and requiring too much time to learn.
In this article, we are going to take on the role of Toto and open the curtain on the secret power of subsystems. We explain exactly what a subsystem is, what elements contribute to its usage of system resources, and how you can use subsystems to better manage your AS/400 work load. Instead of using the technical doublespeak the Wizard might favor, we give you an overview that exposes you to the potential of subsystems without bogging you down in the details. We review each feature of a subsystem and explain how you can use these features to make your shop run more efficiently.
Because, Because, Because, Because, Becauuuse...
Removing the curtain from any technical subject involves definitions of terminology specific to the topic. The glossary on page 104 will help you understand subsystem-related terms when you come across them in boldface type in the article. Of course, in a discussion of the power of subsystems, the first and most obvious question to ask is: What is a subsystem?
Subsystems are user-defined operating environments on the AS/400 that coordinate the flow of work through OS/400. They segment system resources so that jobs can be processed more efficiently. Subsystems do this by creating separate areas in which different types of jobs can run. Interactive subsystems, such as QINTER, service the needs of interactive users. Batch subsystems such as QBATCH service batch jobs. Communication subsystems such as QCMN service jobs that communicate with other machines.
All subsystems are described to the AS/400 through the use of subsystem descriptions that have an AS/400 object type of *SBSD. Certain subsystem descriptions, such as QINTER, QBATCH, QCTL, QCMN, and QSPL, are predefined when you install OS/400 and can be modified. In addition, you can also create any number of user-specific subsystems for your location by using the Create Subsystem Description (CRTSBSD) command.
Subsystems are started with the Start Subsystem (STRSBS) command at IPL time or manually from a display station. They are assigned specific OS/400 resources that can be claimed exclusively by jobs running in that subsystem or shared between two or more subsystems. Each subsystem determines which storage pools its jobs can use, how many jobs can be active within the subsystem at one time, which types of jobs to allow within its environment, and which operating parameters are necessary for each type of job.
Subsystems are the largest component of OS/400's work-management environment. IBM uses the term work management to describe the framework through which all work performed on the system is controlled.
The strength of the subsystem concept is that you can use it to provide as many unique operating environments as necessary to service your installation. Do you want to separate your Order Entry department from all other interactive users so you can tweak processing in the department's favor? Set up an Order Entry department subsystem. If you want to separate production batch jobs from user queries and special reports, set up a high-priority batch subsystem. You have the ability to add and modify subsystems to fit your organization's needs. Subsystems can be as flexible as your environment dictates, with your system resources being the only limiting factor.
Getting Those Ruby Slippers
IBM ships its AS/400s with QBASE and the spooling subsystem, QSPL, configured to run at IPL. All interactive, batch, and communications jobs run out of QBASE. Jobs share the same memory pools and use the same routing entries, job descriptions, and job queues. Very little resource allocation is involved in this arrangement. All jobs compete for all resources, and may the best job win.
When IBM ships an AS/400, QBASE is the controlling subsystem. It is the first subsystem to start after IPL, and it must be active while the AS/400 is running. Other subsystems can be started and stopped, but the controlling subsystem will always stay active. The system console runs out of the controlling subsystem, and its subsystem description cannot be deleted or altered while the AS/400 is running. The only time the controlling subsystem ends is when the AS/400 is powered down.
Unfortunately, if you can't separate interactive, batch, and communications work into separate subsystems, you won't have much work management going on. Since batch jobs run out of the controlling subsystem, you can't suspend batch work by ending QBASE.
A similar situation occurs with interactive work. That's why most installations opt to change this configuration, making subsystem QCTL the controlling subsystem. This setup splits interactive, batch, and communications processing into separate subsystems called QINTER, QBATCH, and QCMN, respectively. Once this basic splitting of the work load occurs, the stage is set for most of the work-management techniques described in this article.
OS/400 gives you the option to specify another subsystem besides QBASE or QCTL as your controlling subsystem. This could be valuable in situations where you want to experiment with parameter changes to QCTL or QBASE while retaining the original unaltered subsystem definition. In this case, you would specify another subsystem that has the ability to run interactive jobs-e.g., signing onto the system console. To change your controlling subsystem, you change the Controlling Subsystem system value, QCTLSBSD, specifying the subsystem description and library of the new controlling subsystem. Refer to the Work with System Values (WRKSYSVAL) or Change System Values (CHGSYSVAL) commands in the CL Reference manual for more information on how to do this.
The controlling subsystem has a designated backup subsystem in case the controlling subsystem description is damaged. This subsystem is called QSYSSBSD in library QSYS. If, for any reason, the controlling subsystem can no longer be used, you can designate this subsystem as a replacement when you do a manual IPL.
Follow the Blue Brick Road
How do you manage subsystems to improve your work flow? The key to drawing back the curtain is to understand the parameters you can change on a subsystem. 1 shows a chart explaining the individual parameters of a subsystem and the CL commands you use to manipulate them.
How do you manage subsystems to improve your work flow? The key to drawing back the curtain is to understand the parameters you can change on a subsystem. Figure 1 shows a chart explaining the individual parameters of a subsystem and the CL commands you use to manipulate them.
To see what parameters have been set for a particular subsystem, you can run the Display Subsystem Description (DSPSBSD) command. To display the QINTER subsystem description, for example, you would type in:
DSPSBSD SBSD(QINTER)
This gives you the display shown in 2. To view a parameter, select the appropriate number and press Enter.
This gives you the display shown in Figure 2. To view a parameter, select the appropriate number and press Enter.
The remainder of this article deals with explaining what each of these options does. Once you understand how these parameters work, you can design your subsystem architecture to suit your particular organization.
Operational Attributes and Pool Definitions
Basically, subsystem parameters are divided up into two specific groups: operational attributes and pool definitions, and work entries. First we'll concentrate on operational attributes and pool definitions, which are the basic building blocks of any subsystem. In order to function properly, a subsystem needs these types of information to tell the AS/400 how it operates.
Operational Attributes
Operational attributes allow you to specify the maximum number of jobs that can be active in each subsystem at one time. This capability is extremely handy for batch job subsystems. Suppose you create a subsystem called NIGHTLY to run your nightly sequential batch jobs. You can force jobs to finish in sequence if you specify that the system can run only one job at a time.
For interactive subsystems, you may want to specify no maximum to the number of jobs that can run in a subsystem at the same time. This is a simple but powerful work-management feature of AS/400 subsystems that you can use to your benefit. When we discuss job queue entries, you'll see how to further refine the number of jobs that can run in your subsystem at one time.
You can display customized sign-on screens by specifying the location of an alternate sign-on display file for any interactive subsystem. These sign-on screens may contain logos or special messages for your users. A practical example might be to change a subsystem's sign-on screen to include the name of your company in block letters when your customers sign on to your AS/400.
3 shows samples of operational attributes and all other subsystem entries. You may refer to the figure as you continue to read about the rest of the entries. Following each entry discussed in this article is a list of relevant CL commands. Refer to the CL Reference manual for more information on these commands.
Figure 3 shows samples of operational attributes and all other subsystem entries. You may refer to the figure as you continue to read about the rest of the entries. Following each entry discussed in this article is a list of relevant CL commands. Refer to the CL Reference manual for more information on these commands.
Related CL commands: CHGSBSD
CRTSBSD
Pool Definitions
Pool definitions let OS/400 know which pools or operating resources a subsystem expects to use. A separate article could easily be written on AS/400 storage pools. Shared storage pools allow you to segment the AS/400's working memory, or main memory, into one of 14 different areas, as shown in 4. These individual pools are then assigned to one or more subsystems as resources to complete processing.
Pool definitions let OS/400 know which pools or operating resources a subsystem expects to use. A separate article could easily be written on AS/400 storage pools. Shared storage pools allow you to segment the AS/400's working memory, or main memory, into one of 14 different areas, as shown in Figure 4. These individual pools are then assigned to one or more subsystems as resources to complete processing.
IBM has defined four pools for managing memory: the *MACHINE pool for the operating system; the *INTERACT pool for interactive processing; the *SPOOL pool for printer spooling; and the *BASE, a shared system pool for all jobs not specifically allocated to another pool. Ten additional shared pools, called *SHRPOOL1 through *SHRPOOL10, can be configured and assigned to user-created subsystems as needed. By splitting up the AS/400's working memory into smaller segments that can be dedicated to individual subsystem tasks, OS/400 allows more work to be accomplished than if every job were fighting for the same system memory.
In a subsystem, storage pool definitions determine what amount of main memory is allocated to jobs running in the subsystem. If you are creating a new subsystem, you can share one of the predefined storage pools with other subsystems or you can carve out a block of memory from the *BASE storage pool to be used solely for that subsystem.
Activity levels can be defined in the same way. This gives you the freedom and flexibility to assign dedicated amounts of memory to jobs running in each subsystem. If you have created a subsystem strictly for order-entry users, they can access a storage pool that is unavailable to other users. You can also assign two or more storage pools to your subsystem and allocate their usage to the types of work that come in.
Individual storage pools are assigned to a subsystem with the Create Subsystem Description (CRTSBSD) and Change Subsystem Description (CHGSBSD) commands.
Related CL commands: WRKSHRPOOL
CHGSHRPOOL
Work Entries
For each subsystem, there is a group of entries that together describe how jobs are selected to run in a subsystem. IBM describes this set of subsystem attributes as work entries. They contain the following items from the subsystem description.
o Job queue entries o Workstation entries o Routing entries o Autostart job entries o Prestart job entries o Communications and remote-location name entries
As the operational attributes and storage pool definitions tell OS/400 how the subsystem operates, work entries tell OS/400 how jobs are run in the subsystem. They designate any and all sources of work the subsystem will handle. Work entries control how jobs enter a subsystem, which jobs become active when a subsystem starts, which interactive workstations can and cannot use the subsystem, which remote devices can start work on your system, which programs will be run, and which jobs can be started in anticipation of a remote location using them. They answer the questions of which users' jobs can enter a subsystem, where these jobs enter from, and what programs they can run.
Job Queue Entries
A job queue entry specifies which job queues are used to submit work to a particular subsystem and how many jobs from each job queue can be running at the same time. Although this seems like a feature that would be used only in batch subsystems, it is also appropriate for interactive subsystems where users transfer jobs between subsystems by using the Transfer Job (TFRJOB) command.
Assigning a job queue entry to a subsystem merely states that the subsystem will accept work, in the form of jobs, from a particular job queue. When you add job queues to a subsystem, you provide a sequence number that allows you to prioritize work going into the subsystem. Jobs from job queues with low sequence numbers are accepted before jobs from queues with higher sequence numbers. Theoretically, you can add 9,999 job queue entries to a subsystem; but a more practical number falls between 1 and 10.
You can also specify how many jobs from each particular job queue can run in a subsystem at one time. If, for example, you have two job queues servicing a subsystem, you can specify that the first job queue have only one job running at a time while the second job queue can have two, three, or more jobs running concurrently in the subsystem. This feature allows you to thread jobs originating from a specific job queue so that certain jobs are guaranteed to finish before other jobs start.
As opposed to the operational attributes, which specify the total number of jobs running in the subsystem, subsystem job queue entries allow you to specify how many jobs from each individual job queue servicing that subsystem can run concurrently. In addition, you can even break down how many jobs of each run priority can operate from a particular job queue at one time. For instance, you can specify that no more than a single job of run priority one can be running while three jobs of priority two and one job of priority three can be running.
Job queue entries work hand in hand with operational attributes to limit the amount of work entering a subsystem. Based on these entries, a subsystem uses the following parameters in deciding whether to begin running another job from this job queue.
1. Is the number of jobs currently running in the subsystem equal to the maximum number of jobs in the subsystem, as defined in the operational attributes?
2. Is the maximum number of jobs from this job queue currently running in the subsystem?
3. Is the maximum number of jobs for this run priority in this job queue currently running?
Related CL commands: CRTJOBQ
ADDJOBQE
CHGJOBQE
Workstation Entries
Workstation entries specify the types of terminals and the specific user terminals that can run jobs in a subsystem. These parameters are used exclusively for interactive subsystems. When specified correctly, only the workstation types and names in the subsystem description can run jobs in that subsystem.
Workstation entries allow you to define access to interactive subsystems by type of device (i.e., 5251, 3197, *ASCII) or by specific or generic device name. Using workstation entries, you can dedicate entire subsystems to groups of users.
For example, remote workstation displays running in an interactive subsystem can slow down local users by making the subsystem wait for a slow response from a remote device. With workstation entries, you can group all remote users with that particular remote display type into their own subsystem, isolating them from the local, interactive users and speeding up processing time for both groups.
Workstation entries can also allow you to specify when a particular workstation or type of workstation can enter a subsystem. With an entry's allocation parameter, you can tell OS/400 that certain workstations can be allocated to a subsystem at the sign-on screen or that those workstations can only enter the subsystem through the TFRJOB command. TFRJOB allows you to transfer a job and all its temporary objects from one subsystem to another. By using the allocation parameter and TFRJOB, you can designate one subsystem as a workstation's home subsystem and grant it access to other subsystems as the need arises.
You can also segment certain groups of users by subsystem. As mentioned earlier, you could use this strategy to place all users in the Order Entry department into their own subsystem.
For an explanation of how to create multiple interactive subsystems and restrict access to them using workstation entries, refer to "Multiple Interactive Subsystems," MC, December 1993. This article also discusses the TFRJOB command mentioned earlier.
Again, all this adds to the flexibility of your operating system. With workstation entries, you can create separate environments for groups of terminals or specific workstations.
Related CL commands: ADDWSE
CHGWSE
RMVWSE
Routing Entries
When a subsystem is started, it initiates a special job called a subsystem monitor to look for work and route it to the appropriate resources. The monitor assigns the proper memory pool to use, the processing program to run, and the operational attributes to use for the job. Each subsystem on the AS/400 uses routing entries to accomplish these goals.
All jobs on the AS/400 except prestart jobs use routing data. Routing data is usually retrieved from the job description. When the subsystem monitor starts a job, the value in this routing data field is compared against the values in the Compare Value field of each routing entry in the subsystem. If a match is found, the program listed on the matching routing entry is called.
If an exact match is not found and a routing entry with a Compare Value of *ANY exists, the subsystem monitor will run the program listed in the *ANY routing entry.
If no match is found and there is no routing entry with a Compare Value of *ANY, the subsystem monitor terminates that job. By using routing data the subsystem determines the processing program to run.
In addition, a routing entry contains the subsystem pool ID to be used when running the program. This is the pool ID described in the storage pool definitions in the section on pool definitions. A '1' in the pool ID field of a routing entry means the program should use the first storage pool assigned to the subsystem. A '2' specifies the second pool assigned; a '3' specifies the third pool, and so on. The storage pool IDs can differ for every subsystem and are specific to each subsystem.
In the routing entry, OS/400 gives you another tool to manage the number of jobs that can run in a subsystem. This time, the management occurs at the program level. A routing entry performs job management through its maximum active routing steps parameter. A routing step is simply an AS/400 program that is started for a job through a routing entry. Each job can have only one active routing step at a time.
This parameter specifies the number of AS/400 jobs that can be active at any one time through this routing entry. The valid values range from 1 to 1,000. The parameter default, *NOMAX, simply means that there is no limit. If you specify a maximum number of jobs for an entry and that maximum is passed, the job requesting a routing step fails and is ended by the subsystem.
The final parameters the routing entry contributes to the job are the job's run-time attributes. These attributes are determined by the class specified on the selected routing entry. The subsystem retrieves the name and library of the class to be used from the routing entry and takes its job attributes from that class. Classes are defined separately on the AS/400 and can be shared between routing entries in several different subsystems.
The specified class gives the job its run priority, time slice, purge *YES/*NO value, default wait time, maximum CPU usage time, and maximum temporary storage.
All of these features have practical implications for work management. In batch, interactive, and communication subsystems, you can assign users to different storage pools or use different programs by changing the routing entries. You can also change the run-time attributes of batch and interactive jobs by changing the class defined on a routing entry. If you have a second interactive subsystem for order processing, you can create a special class for the Order Entry department that runs interactive jobs at priority 19. All jobs entering that subsystem will then run at a higher priority than jobs from other interactive users.
By modifying the routing entries in a subsystem, you are changing the run-time attributes for any jobs running in that subsystem. Although this is an effective way to balance your work load, it can also tilt your system off balance if it's not done with careful planning.
Related CL commands: CRTCLS
CHGCLS
ADDRTGE
CHGRTGE
RMVRTGE
Autostart Job Entries
Autostart job entries designate jobs that start automatically whenever a subsystem becomes active. These entries are often used in communications, when a particular program must be running as that communications subsystem be-comes active. They are also useful for initializing other jobs.
Autostart jobs are used in conjunction with routing entries and job descriptions. One way to create an Autostart job is to first add a routing entry with unique routing data to your subsystem. The program on this routing entry should be the program you wish to run on subsystem start-up. You then create a job description that includes all the necessary operational information such as the library list and the matching routing data for your new routing entry. Finally, you create an autostart job entry for your subsystem that activates the new job description upon initialization. When the autostart job entry is processed at subsystem start-up, the program will be started by the routing entry that matches the job description's routing data.
A second way to accomplish this is a slight twist on the first method. Instead of creating a new routing entry and placing the matching routing data into the job description, you place a command directly into the Request Data parameter of the job description and specify the routing data for the job description as *RQSDTA. This will cause the command line in the routing data, whether it is an OS/400 command or a program call, to execute when the autostart entry is processed. This bypasses the routing entries and runs the program immediately upon subsystem start-up. By using this second approach, you avoid adding an additional routing entry to your subsystem. Using this technique is similar to using the command line parameter in the Submit Job (SBMJOB) command.
Autostart jobs are started only when the subsystem monitor begins. If for any reason your autostart job is canceled after the subsystem is running, it will not automatically begin again until the next time the subsystem is started. As a consequence, when a user-written autostart job fails, the program must be restarted manually if the subsystem cannot be ended and started again.
Related CL command: ADDRTGE
CHGRTGE
ADDAJE
CHGAJE
CRTJOBD
Prestart Job Entries
Prestart job entries define jobs that are started in a subsystem in anticipation of a user at a remote site needing to run a particular program. They are designed to cut down on the amount of access time a remote user needs to log on to your AS/400, start up a program, open up any needed files, and initialize the working environment. A prestart job waits for a program start request from a remote system; when a match is found (program name or routing data), the request is attached to an existing prestart job.
The prestart job function is available to all communication protocols that support program-start-request (PSR) processing. It is particularly valuable in applications when quick answers are needed, such as when remote sites are calling a central warehouse for inventory levels.
Prestart jobs are started by the subsystem monitor when the subsystem is started. When you define a prestart job, you specify the program and library, the user profile to use on your host AS/400, the initial number of jobs to start with this entry, additional prestart jobs that can be started for the program, and the total number of jobs that can be started from this entry.
When these jobs are started, they always run with the authority of the user profile specified on the entry. When a user passes in a different user profile and password with a program start request, that profile is checked for security purposes; but the program is always run with the authority of the prestart entry user. This creates a situation in which several different users can access the same program without having to update their authority to the program or the files it accesses. You tighten your database security by only allowing access to the files when your users are running the program.
Related CL commands: ADDPJE
CHGPJE
Communications Entries and Remote Location Name Entries
Although communications entries and remote location name entries are listed as two different items in a subsystem description, they are essentially the same thing. They provide job attributes for communications jobs, and they are both entered into the subsystem description as a communications entry using the Add Communications Entry (ADDCMNE) command.
The difference is that subsystem communications entries are defined for devices (*APPC, *ASYNC, *INTRA) while remote location name entries are defined for remote location names that are connecting to the AS/400.
When a remote user queries the AS/400 for access, its device name, remote location, and device type are checked against the defined communications entries. When it finds a match, the entry specifies the job description to be used for retrieving routing data, the security level to be used, and the maximum number of jobs that can enter the subsystem through this entry.
Once the calling system has passed through communications security, it uses the routing data from the entry's specified job description for any jobs that are created. All PC Support communication jobs are created through these entries as well as all pass-through jobs. Any job started on your AS/400 through a communications card will be routed through a communications entry. Asynchronous, token-ring, Ethernet, and all other communication jobs are also routed through communication entries that create, or evoke, other jobs in the system.
Job security can be enforced by requiring the user to sign on for evoked jobs, or it can be assumed by using a default user profile that can be specified for certain IBM transaction jobs.
As with the operational attributes and the job queue entries, these entries can limit access to the system by setting a limit on the maximum number of jobs that enter the system through a communications or remote location entry. This has the same effect as the maximum numbers in the other entries. Once the limit has been reached, no other jobs are started in the subsystem through this entry.
In order to handle possible conflicts when more than one subsystem contains the same communications/remote location name entries for a communications device, OS/400 uses the following scheme to determine which subsystem and entry will allocate the device when it becomes available.
1. Communication entries that specify device names are checked first. If the device name of the calling device is listed, that communications entry is used.
2. Remote location entries are then checked and used if a match is found.
3. Communications entries for device name *ALL are checked to see if the device type on each entry is equal to the device type of the calling device. If it is, that entry is used.
4. If two or more subsystems have the same communications entry or remote location name entry and they both request the incoming communications device (a tie), the AS/400 seniority system kicks in and the subsystem that was started first allocates the device.
Related CL commands: ADDCMNE
CHGCMNE
What? No Lions or Tigers or Bears?
As you can see, the road jobs take to run on the AS/400 is, in many instances, more complicated than the one Dorothy and her friends took to see the Wizard. If you remember the basics of how subsystems fit together, it becomes much easier to manage your own AS/400.
o Operational attributes and pool definitions tell the AS/400 what resources a subsystem needs and define how many jobs can be running in the subsystem at one time.
o Job queue entries specify which job queues service each subsystem and sequence the work that enters a subsystem.
o Workstation entries define which interactive workstations can enter your subsystem.
o Routing entries determine what program a job runs to get started and what run-time attributes to use for each job.
o Autostart jobs begin at subsystem start-up and perform job initialization or continuous service.
o Prestart jobs cut down on the initialization time needed for high-access communications jobs, such as warehouse stock inquiries, by providing preset processing environments remote users can plug into when they communicate with the AS/400.
o Communications and remote location name entries provide job attributes for jobs that are started, or evoked, from a remote location. They also control access to a subsystem by providing additional security and limiting the number of communications jobs that can be running.
Once you understand these basic concepts, you can begin to pull back the curtain on subsystems and start determining how they can help you manage your own work flow.
Joe Hertvik is a freelance writer and system administrator for a manufacturing company outside of Chicago.
REFERENCES
CL Reference (SC41-0030, CD-ROM QBKA8202).
Work Management Guide (SC41-8078, CD-ROM QBKA9J02).
GLOSSARY
The following are some additional definitions that were not described in the main article:
Activity Level-Defined for all AS/400 storage pools, the maximum number of jobs that can access the storage pool's memory at one time If the activity level of the pool is less than the number of jobs trying to run in the pool (access the pool's memory), the remaining jobs go into an ineligible state until an activity level becomes free.
Class-An object that contains operational parameters for running a job created through a routing entry.
Job Description-An object that tells OS/400 how you want the system to process a job. This includes the name of the default job queue, message logging parameters, job switches, run and printer- output priorities, and the routing data.
Job Queue-An OS/400 object that accepts requests for jobs to be run in a subsystem until the Subsystem Monitors can actually start the job in the subsystem.
Operational Attributes-Subsystem parameters that define global attributes of a subsystem, such as the maximum number of jobs, customized sign-on screens, and a subsystem library list.
Pool Definitions-Specifies the division of main or auxiliary storage used by a subsystem. On the AS/400 system, all main storage can be divided into logical allocations called storage pools (shared and private).
Routing Data-Information contained in each incoming job that specifies the routing entry to be used to start that job.
Storage Pools-A user-defined subdivision of the AS/400s working memory into 14 different shared pools that can be allocated to specific subsystems for more efficient job processing.
Subsystem-Separate user-defined environments in the AS/400 that coordinate the flow of work through OS/400.
Subsystem Monitor-A subsystem job that assigns resources to incoming jobs based on the information in the subsystem description.
Work Entries-Subsystem parameters that describe how jobs are run in a subsystem.
Work Management-A software framework within OS/400 that controls the system and all the work performed on the system. Work management functions allow work to be submitted to the machine for processing and they manage competition between jobs for storage and system resources.
Working (Main) Memory-Similar to RAM in a personal computer, the working memory OS/400 uses to run programs and modify data.
Solving the Mystery of Subsystems
Figure 1 Subsystem Parameters and Associated Commands
Subsystem Parameter What It Does Command Abbrev.
Operational Attributes Defines maximum Create Subsystem CRTSBSD
number of jobs in Description
subsystem and
location of
sign-on display.
Pool Definitions Defines storage Create Subsystem CRTSBSD
pools a subsystem Description
uses
Job Queue Entries Queues and services Add Job Queue ADDJOBQE
jobs entering Entry
a subsystem.
Sequences work
entering a subsystem.
Workstation Name and Defines which Add Work Station ADDWSE
Workstation Type workstations can Entry
Entries access a subsystem.
Routing Entries Determines program Add Routing Entry ADDRTGE
(command-processing
or user-written
program) and job
attributes a job
uses in a subsystem. Create Class CRTCLS
Autostart Entries Defines automated Add Autostart Job ADDAJE
jobs that begin at Entry
subsystem start-up.
Add Job ADDJOBD
Description
Add Routing Entry ADDRTGE
Prestart Entries Defines a preset Add Prestart Job ADDPJE
processing Entry
environment for
remote users.
Add Communications ADDCMNE
Entry
Communications and Defines job Add Communications ADDCMNE
Remote Location Name attributes and Entry
Entries security for jobs
started from a
remote system.
Solving the Mystery of Subsystems
Figure 2 Display Subsystem Description
Display Subsystem Description
System: MCPGMR
Subsystem description: QINTER Library: QSYS
Status: ACTIVE
Select one of the following:
1. Operational attributes
2. Pool definitions
3. Autostart job entries
4. Work station name entries
5. Work station type entries
6. Job queue entries
7. Routing entries
8. Communications entries
9. Remote location name entries
10. Prestart job entries
More...
Selection or command
===>
__________________________________________________________________________
_______________________________________________________________________________
F3=Exit F4=Prompt F9=Retrieve F12=Cancel
Solving the Mystery of Subsystems
Figure 3 Samples of All Subsystem Entries
Sample Operational Attributes
Subsystem description . . . . . . . . . . . . . : SBSD QINTER
Library . . . . . . . . . . . . . . . . . . . : QSYS
Maximum jobs in subsystem . . . . . . . . . . . : MAXJOBS *NOMAX
Sign-on display file . . . . . . . . . . . . . . : SGNDSPF QDSIGNON
Library . . . . . . . . . . . . . . . . . . . : QSYS
System library list entry . . . . . . . . . . . : SYSLIBLE *NONE
Sample Pool Definitions
Pool ID Storage Size (K) Activity Level
1 *BASE
2 *INTERACT
Sample Job Queue Entries
Seq Nbr Job Queue Library Max Active Maximum by Priority
1 2 3 4 5 6 7 8 9
10 QINTER QGPL *NOMAX *NOMAX *NOMAX *NOMAX *NOMAX *NOMAX
*NOMAX *NOMAX *NOMAX *NOMAX
20 QS36MRT QGPL *NOMAX *NOMAX *NOMAX *NOMAX *NOMAX *NOMAX
*NOMAX *NOMAX *NOMAX *NOMAX
Sample Workstation Entries
Subsystem description . . . . . . . . . . : QINTER Status . . . . :
Active
Work Station Type Entry
Work station type . . . . . . . . . . . . : WRKSTNTYPE *ALL
Job description . . . . . . . . . . . . . : JOBD *USRPRF
Maximum active jobs . . . . . . . . . . . : MAXACT *NOMAX
Control job at . . . . . . . . . . . . . : AT *SIGNON
Subsystem description . . . . . . . . . . : QINTER Status . . . . :
Inactive
Work Station Name Entry
Work station name . . . . . . . . . . . . : WRKSTN MIS*
Job description . . . . . . . . . . . . . : JOBD *USRPRF
Maximum active jobs . . . . . . . . . . . : MAXACT *NOMAX
Control job at . . . . . . . . . . . . . : AT *SIGNON
Sample Routing Entries
Seq Nbr Program Library Compare Value Start Pos
10 QCMD QSYS 'QCMDI' 1
20 QCMD QSYS 'QS36MRT' 1
40 QARDRIVE QSYS '525XTEST' 1
700 QCL QSYS 'QCMD38' 1
9999 QCMD QSYS *ANY
Routing Entry Detail
Routing entry sequence number . . . . . . . . . . : SEQNBR 10
Program . . . . . . . . . . . . . . . . . . . . . : PGM QCMD
Library . . . . . . . . . . . . . . . . . . . . : QSYS
Class . . . . . . . . . . . . . . . . . . . . . . : CLS QINTER
Library . . . . . . . . . . . . . . . . . . . . : QGPL
Maximum active routing steps . . . . . . . . . . . : MAXACT *NOMAX
Pool identifier . . . . . . . . . . . . . . . . . : POOLID 2
Compare value . . . . . . . . . . . . . . . . . . : CMPVAL 'QCMDI'
Compare start position . . . . . . . . . . . . . . : 1
Sample Autostart Job Entries
Job Job Description Library
MRCAUTO MRCJOBD MRCLIB
Sample Prestart Job Entries
Program Library User Profile
JRN JOE QUSER
Prestart Job Entry Detail
Program . . . . . . . . . . . . . . . . . . . . . . . : PGM JRN
Library . . . . . . . . . . . . . . . . . . . . . . : JOE
User profile . . . . . . . . . . . . . . . . . . . . . : USER QUSER
Job . . . . . . . . . . . . . . . . . . . . . . . . . : JOB JRN
Job description . . . . . . . . . . . . . . . . . . . : JOBD *USRPRF
Start jobs . . . . . . . . . . . . . . . . . . . . . . : STRJOBS *YES
Initial number of jobs . . . . . . . . . . . . . . . . : INLJOBS 3
Threshold . . . . . . . . . . . . . . . . . . . . . . : THRESHOLD 2
Additional number of jobs . . . . . . . . . . . . . . : ADLJOBS 2
Maximum number of jobs . . . . . . . . . . . . . . . . : MAXJOBS *NOMAX
Maximum number of uses . . . . . . . . . . . . . . . . : MAXUSE 200
Wait for job . . . . . . . . . . . . . . . . . . . . . : WAIT *YES
Pool identifier . . . . . . . . . . . . . . . . . . . : POOLID 2
Class:
Class . . . . . . . . . . . . . . . . . . . . . . . : CLS QBATCH
Library . . . . . . . . . . . . . . . . . . . . . : QGPL
Number of jobs to use class . . . . . . . . . . . : *CALC
Class . . . . . . . . . . . . . . . . . . . . . . . : *NONE
Number of jobs to use class . . . . . . . . . . . : *CALC
Sample Communications Entries
Device Mode Job Description Library Default User Max Active
USER01 *ANY *USRPRF *NONE *NOMAX
Sample Remote Location Name Entries
Remote Location Mode Job Description Library Default User Max Active
REMOTE01 *ANY *USRPRF *NONE *NOMAX
Solving the Mystery of Subsystems
Figure 4 Shared Pools Available on the AS/400
Work with Shared Pools
System: MCPGMR
Main storage size (K) . : 28672
Type changes (if allowed), press Enter.
Defined Max Allocated Pool -Paging Option--
Pool Size (K) Active Size (K) ID Defined Current
*MACHINE 6750 +++ 6750 1 *FIXED *FIXED
*BASE 9772 10 9772 2 *CALC *CALC
*INTERACT 12000 13 12000 4 *CALC *CALC
*SPOOL 150 3 150 3 *CALC *CALC
*SHRPOOL1 0 0 *FIXED
*SHRPOOL2 0 0 *FIXED
*SHRPOOL3 0 0 *FIXED
*SHRPOOL4 0 0 *FIXED
*SHRPOOL5 0 0 *FIXED
*SHRPOOL6 0 0 *FIXED
More...
Command
===> _________________________________________________________________________
F3=Exit F4=Prompt F5=Refresh F9=Retrieve F11=Display text
F12=Cancel
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online