How a 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:

Request to start subsystem is issued. The Start Subsystem (STRSBS) command is issued. Key startup information is located in the subsystem description.
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 storage pool is less than the minimum size specified by the Base memory pool minimum size system value QBASPOOL. 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.
Prestart jobs are started. This information comes from the prestart job entries.
Autostart jobs are started. This information comes from the autostart jobs entries.
Display stations are allocated (signon displays are up). 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 signon display. If the device is varied on and has been allocated by another subsystem and is at the signon display (the signon display was displayed before the second subsystem was started), a second subsystem can allocate the device from the first subsystem and display the signon display. If the device is not varied on, the subsystem cannot allocate it. The system arbiter (QSYSARB) and the QCMNARB jobs hold locks on all varied-off devices. Workstation entries provide the information about what devices to check for allocation.
Note: For virtual display devices, the signon prompt is displayed when the device becomes fully varied on. This happens when a user connects to the iSeries™ using that device description (assuming the connection request does not carry the data that is used to bypass the signon prompt processing). A device can be taken from a pool of previously created device descriptions and varied on as part of that connection processing, or a device can be created and varied on. At a subsystem start, the subsystem will pend a lock for any of the previously created device descriptions that it wants.
Job queues are allocated. The subsystem will not be able to allocate a job queue if it is already allocated to another active subsystem. This information comes from the job queue entries.
Communications devices are allocated. Requests are sent to the QLUS (LU services) system job, which handles device allocation for all communications devices. This information comes from the communication entries.
The Environment is ready for work.