Years ago, when TCP/IP was starting to become the networking standard of choice, it was not automatically when the system was started. You had to edit the system start-up program to automate starting TCP/IP and related interfaces and servers.
In the V5R1 release, the work management component provided the ability to automatically start TCP/IP when the system was started with the addition of the IP attribute “Start TCP”. The default is *YES, but you can change it to *NO to control the starting of TCP/IP yourself.
When the system automatically starts TCP/IP, it does so after the controlling subsystem has started; thus this support works for coming out of restricted state as it does for a partition IPL. When starting from an IPL or restricted state, work management also starts the QSYSWRK subsystem. QSYSWRK is required for TCP/IP functionality since many of the daemon jobs run in that subsystem; the start TCP/IP processing job (QSTRTCP) also runs in QSYSWRK.
When the STRTCP command is left as shipped by IBM, the start TCP processing will first start the defined IPv4 interfaces, the IPv6 interfaces, and the Point to Point (PPP) profiles. The STRTCP processing submits a job named QTCPSTSVRS which starts the application servers. This job is not synchronized with other STRTCP processing, so it can begin to start servers before the interfaces have all been started. TCP Server start-up processing should handle these dependencies and have retry logic if necessary. You configure TCP application servers to start with TCP/IP by specifying the “Start with TCP/IP is started” or the “Autostart” attribute. The blog I wrote earlier this year, Automatically Starting TCP Servers when TCP/IP is Started, discusses this in more detail.
Another important change occurred in the 6.1 release. Prior to 6.1, when TCP/IP was started, it would start the QTCPIP and QTCPMONITR jobs in the QSYSWRK subsystem and these jobs controlled TCP/IP. However, if these jobs were ended, then TCP/IP would also end. To improve the reliability and availability of TCP/IP, these jobs in QSYSWRK are no longer used and the QTCPCTL and QTCPWRK system jobs are used instead. The QTCPCTL job is responsible for managing requests that are sent to the QTCPWRK job. The QTCPWRK job manages the starting and ending of TCP/IP, and the starting and ending of interfaces and PPP profiles. The QTCPWRK job also acts as a message relay agent for TCP/IP related messages. This allows the TCP/IP protocol stack to remain active when in restricted state. Typically, the restricted state is for tape back-ups that use TCP/IP. Refer to the 6.1 Memo to Users for more information on the change to system jobs for TCP/IP processing.
I have heard about clients having issues reliably stating TCP/IP servers when starting TCP/IP at IPL or when starting from restricted state. This can be due to the dependencies between subsystems and the server jobs. Some server jobs run in subsystems other than QSYSWRK; some servers allow you to customize the subsystem in which they run. If the subsystems required by a TCP server are not started before the server jobs are started, problems can result. If you have problems with TCP/IP servers automatically starting after an IPL or coming out of restricted state, you can customize the system's start-up program (specified by the QSTRUPPGM system value) to control starting the subsystems and server jobs.
IBM has a support knowledge-base article titled “Starting TCP - Using the IPL Attributes Versus the System Startup Program”. If you call IBM Support with a problem related to the STRTCP processing at IPL, the IBM support representative may discuss the information documented in this article.
However, the STRTCP IPL attribute processing has improved over the years and using that IPL attribute is the recommended way to STRTCP. If you have specific errors when using the IPL attribute to start TCP/IP, IBM support will need to know the details (Is TCP not starting as a whole? Is a specific server not starting? etc.). It is possible that more complex environments may need to use a customized start-up program to get all the servers correctly started.
However, if you encounter server start-up problems, or if you can recreate problems that cause you to add DLYJOBs to your start-up program, you should open a PMR so the IBM development team can understand the issue and work on a resolution.
Finally, the IBM i Information Center has a section on TCP/IP Troubleshooting. Within that documentation there is a section on Timing Considerations that reviews the general considerations for setting up your own start-up program to start TCP/IP and TCP Servers.