AUTOLOG statement

Use the AUTOLOG statement to provide a list of MVS™ started procedures to be started by the Autolog task when TCP/IP is started.

In addition to initially starting these procedures, the AUTOLOG statement can provide a monitoring function that ensures that these started procedures are still active. To request this monitoring function for a started procedure, reserve one or more ports for the procedure using the PORT or PORTRANGE profile statement. Do not specify the NOAUTOLOG parameter. The proc_name or JOBNAME value on the AUTOLOG statement entry must match the jobname value on the port reservation statement. Every 5 minutes, the autolog monitoring function ensures that there is either a TCP listening socket, or a UDP socket, active for those port reservations where:

• NOAUTOLOG was not specified
• The jobname matches the AUTOLOG statement proc_name or JOBNAME value

If no active socket is found for any of the reserved ports for the started procedure, then the Autolog monitoring function performs the following actions:

• Determines if the started procedure address space is still active. If it is still active, the autolog function cancels the started procedure.
  Note: If the started procedure has multiple reserved ports (for example, INETD1) and if any one of those ports does not have an active socket, the autolog function will cancel the started procedure. This can cause disruption to the active sockets for the other reserved ports for that started procedure address space.
• Restarts the started procedure.

Guideline: Ensure that ports that are used by the started procedure (for example, in /etc/services or specified on an optional port parameter for the started procedure) match the reserved ports in the port reservation statement. A mismatched port can cause the autolog monitoring function to cancel the started procedure.

Restriction: Do not use AUTOLOG to automatically start generic servers (those without affinity to a specific stack, such as TN3270E and FTP) when multiple stacks (CINET) are running. Do not use AUTOLOG to automatically start servers defined as non-cancelable (such as TN3270E) in the program properties table (PPT). Instead, use a method other than AUTOLOG to automatically start generic servers. For more information about generic servers, see z/OS Communications Server: IP Configuration Guide.

Parameters

wait

The time TCP/IP should allow for a procedure to come down when, at startup, it is still active and TCP/IP is attempting to AUTOLOG the procedure again. This could happen if the procedure did not come down when TCP/IP was last shut down.

The default is 5 minutes. wait can be set to any value from 0 to 30 minutes. If a wait value outside the valid range is specified, the default of 5 minutes is used. When a wait value of 0 is specified, TCP/IP startup does not cancel and restart any procedures in the autolog list that are already started.

TCP/IP does not cancel the procedure at initialization. TCP/IP checks every 10 seconds (until the time interval specified by wait has expired) to check if the procedure has come down. If the procedure comes down during one of these 10 second intervals, it is restarted. If the procedure is still active when the time interval specified by wait expires, then TCP/IP cancels and restarts the procedure.

This value is only used at startup of TCP/IP and is never referenced again.

proc_name

A procedure that the TCP/IP address space should start.

Requirement: The procedure name must be a member of a cataloged procedure library.

PARMSTRING "parm_string"

A string to be added following the START procedure_name. Do not include the comma. The "parm_string" is 115 characters or less, not counting the double quotation marks around the string.

Restriction: The entire "parm_string" must be on one line and must not contain a double quotation mark.

JOBNAME job_name

The job name used for the PORT reservation statement. This can be identical to the proc_name, but for z/OS® UNIX jobs that spawn listener threads it is not. If the job_name is not explicitly set, it is assumed to be the same as the proc_name.

DELAYSTART

An optional keyword that indicates that the procedure does not start until the TCP/IP stack has completed one or more processing steps. One or more optional subparameters determine which processing steps must be completed before the procedure is started. If no additional subparameters are configured, then the procedure is started after the TCP/IP stack has joined the sysplex group and has processed its dynamic VIPA configuration.

If this keyword is not specified, the procedure is started after the TCP/IP stack is started, whether or not the stack has completed any of the processing steps.

DVIPA

When this subparameter is specified, the procedure starts after the TCP/IP stack has joined the sysplex group and has processed its dynamic VIPA configuration. This is the default setting that occurs if DELAYSTART is coded without any subparameters.

Guideline: Use this subparameter to delay the start of a procedure that binds to a dynamic VIPA address that is created during TCP/IP stack initialization or when the procedure performs the bind. Dynamic VIPAs cannot be created until after the stack has joined the sysplex group and has processed its dynamic VIPA configuration; this keyword prevents the procedure from starting before the dynamic VIPA can be created. For information about when the TCP/IP stack joins the sysplex group, see sysplex problem detection and recovery in z/OS Communications Server: IP Configuration Guide.

Tip: The stack issues console message EZD1214I INITIAL DYNAMIC VIPA PROCESSING HAS COMPLETED FOR jobname when dynamic VIPA configuration processing is complete. After this console message is displayed, the autolog procedures waiting on this processing start.

TTLS

When this subparameter is specified, the procedure starts after the Policy Agent has successfully installed the AT-TLS policy in the TCP/IP stack and AT-TLS services are available.

Guideline: Use this subparameter to delay the start of the procedures that depend on AT-TLS services.

Tip: The message EZZ4250I AT-TLS SERVICES ARE AVAILABLE FOR jobname is issued after the Policy Agent has installed the policy and the AT-TLS services are available. After this console message is issued, the autolog procedures waiting on this processing start.

Rules:

• Do not specify the DELAYSTART DVIPA (or DELAYSTART with no subparameters) for your OMPROUTE procedure if you configure the DELAYJOIN parameter on the GLOBALCONFIG profile statement.
• If TCPCONFIG TTLS is not specified in the initial profile, the DELAYSTART TTLS subparameter is ignored because AT-TLS services are not being used.

Results:

• When more than one DELAYSTART subparameter is specified, all of the processing steps defined for those subparameters must complete before the procedure is started.
• When at least one DELAYSTART subparameter is specified, but DVIPA is not specified, the default behavior does not occur; the procedure does not wait for dynamic VIPA configuration processing to complete before starting.

ENDAUTOLOG

The ENDAUTOLOG statement specifies the end of the AUTOLOG parameters to pass to TCP/IP.

Steps for modifying

To modify the AUTOLOG statement, use the VARY TCPIP,,OBEYFILE command with a data set that contains a new AUTOLOG statement. The first AUTOLOG statement in the data set replaces all previous AUTOLOG statements. Subsequent AUTOLOG statements in the same data set append to the previous statements in the data set.

For more information about the VARY TCPIP commands, see z/OS Communications Server: IP System Administrator's Commands .

Usage notes

The AUTOLOG statement can be used to start both socket and non-socket applications. For any procedure that has no port reserved in the PORT statement, AUTOLOG initially starts the procedure when TCP/IP starts. For procedures whose ports are reserved in the PORT statement (and do not have the NOAUTOLOG option specified), each port is checked to make sure that the procedure has an active connection to that port. If a procedure has multiple ports reserved and any one port is inactive, the procedure is canceled and restarted. For TCP connections, the procedure must have a socket open to that port in the LISTEN state. For UDP connections, the procedure must have a socket open to that port.

Related topics

• PORT statement
• PORTRANGE statement