Timing considerations

Timing considerations during startup can affect network communications.

i5/OS™ has the capability to automatically start the necessary subsystems, the TCP/IP stack, lines, interfaces, and servers at the appropriate times during IPL. In most situations, your network communications will start smoothly using this automatic startup process.

However, depending on your unique hardware and software configuration you might have problems starting the network communication due to timing problems during IPL. Timing problems can occur for several different reasons. For example:
  • The processing speed and the number of input-output processors (IOPs) can affect the startup of the network hardware resource. If your hardware resource is slow to start, it might not be ready when TCP/IP tries to start. Your network communications fail because the TCP/IP interfaces cannot be started.
  • You might encounter timing problems if you have customized your server so that you are using subsystems other than the IBM-supplied subsystems. Many subsystems are typically started by the IPL startup program. However, if you are using customized subsystems that are not recognized by the IPL startup program, they will not be automatically started at IPL. Your network communications fail because these subsystems have not been started.

If these types of timing problems occur, you can automatically start the subsystems, the TCP/IP stack, interfaces, and servers in the correct order by creating a customized IPL startup program. You might need to put delays in the startup program to ensure that each step of the startup process is initiated at the appropriate time. For example, the subsystems should be started before the TCP/IP stack, and the interfaces should be started after the communications resources are available.

To change from using the default IPL startup program to using a customized startup program, follow these steps:

  1. Create a customized startup program. Things to consider when creating a new startup program:
    Note: These steps are defined to ensure that all required resources are active before the next step.
    • Start the subsystems.
    • Allow delays after the subsystems start.
    • Use the Retrieve Subsystem Information (QWDRSBSD) API to ensure that the subsystems are active. Although this API is not required, it can help you avoid timing problems.
    • Start TCP/IP specifying STRSVR *NO, STRIFC *NO and STRPTPPRF(*NO).
      Note: You will start TCP/IP for both IPv4 and IPv6 by performing this step. If you do not want start IPv6, specify STRIP6 (*NO) on the STRTCP command.
    • Start the interfaces with STRTCPIFC *AUTOSTART. Remember that TCP/IP should vary on your communication lines, controllers, and devices.
    • Allow delays to ensure the required interfaces are active.
    • Start the TCP/IP point-to-point session jobs with STRTCPPTP *AUTOSTART.
    • Start the servers with STRTCPSVR *AUTOSTART.
    • Start any other servers that are not started with the STRTCPSVR command. Use STRHOSTSVR *ALL.
  2. Test the customized startup program by calling the program. To properly test the program you need to end TCP/IP and the subsystems. However, be aware this can terminate the connections that other users are using. Plan accordingly to test when the system is dedicated to the test.
  3. Change the QSTRUPPGM system value to point to your customized start-up program. It is not recommended to directly change QSTRUP.
  4. Change the IPL attribute to no longer start TCP/IP automatically when the system is started. To change the IPL attribute, follow these steps:
    1. At the command line, type CHGIPLA (Change IPL Attributes), and press F4.
    2. For the Start TCP/IP prompt, type *NO. This prevents TCP/IP from starting at IPL, letting your startup program control the startup.
Parent topic: Verify system startup considerations for networking