Running your system using multiple subsystems is a better choice than running all jobs in QBASE because each subsystem is specialized for a certain kind of work, and you can exert better control of the system. Tuning the i5 for performance also becomes easier.
The three main subsystems discussed in this section—QCTL, QINTER, and QBATCH—are already provided by IBM with your i5.
QCTL is the controlling subsystem. It is called QCTL because it controls the system and is also the subsystem to which the system console is attached.
If you end subsystem QCTL, you end all subsystems automatically. If you restart subsystem QCTL, you restart all subsystems automatically, because QCTL is the controlling subsystem.
QCTL should not be used for regular application software jobs (either interactive or batch) because doing so would degrade system performance. QCTL should be reserved for the system console only.
QINTER is the interactive subsystem. Interactive jobs should run in QINTER. Batch jobs never should run in QINTER; doing so will degrade performance. Use QINTER to sign on to all display stations except the system console. Never submit a batch job to job queue QINTER.
Ending subsystem QINTER affects all display stations except the console. If a display station is showing the sign-on display, the display station is made unavailable. The sign-on display disappears, and the cursor moves to the top-left corner of the screen. If you use OPTION(*CNTRLD) in the ENDSBS command when you end QINTER, all interactive jobs are allowed to continue for the amount of time (in seconds) specified by the DELAY parameter.
If you end QINTER with OPTION(*IMMED), however, all interactive jobs are terminated immediately and will produce job logs.
When you run the system in multiple subsystems, ending QINTER is the easiest way to prevent your users from using the system.
When you start QINTER, the system will show the sign-on display on all display stations again.
Use QBATCH to process batch jobs. Batch jobs are jobs that do not carry on a conversation with a user. To create a batch job, submit a CL command to a job queue for processing. The request remains on the job queue until its turn to run. QBATCH is specially designed to run batch jobs, and will perform poorly with interactive jobs.
Ending QBATCH is the easiest way to hold all submitted batch jobs. If you specify OPTION(*CNTRLD) DELAY(*NOMAX), all batch jobs currently running are allowed to continue until they end normally. If you specify a value other than *NOMAX in the DELAY parameter, the jobs can continue for the number of seconds indicated. This is not, however, a good option for batch jobs.
Resist the temptation to specify option(*IMMED) because many batch jobs perform mass updates of some kind. Forcing them to end immediately can result in a mangled database.