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:
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:
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.
Rule: Specify the parameters in the order shown. The optional parameters following the proc_name parameter can be specified in any order.
.------------------------. .-5----. V | >>-AUTOLog--+------+----proc_name--| Options |-+--ENDAUTOLOG--->< '-wait-' Options |--+---------------------------+--+------------------+----------> '-PARMSTRING " parm_string"-' '-JOBNAME job_name-' >--+--------------------------+---------------------------------| | .-----------. | | V .-DVIPA-. | | '-DELAYSTART---+-------+-+-' '-TTLS--'
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.
Requirement: The procedure name must be a member of a cataloged procedure library.
Restriction: The entire "parm_string" must be on one line and must not contain a double quotation mark.
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.
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.
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:
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 .
AUTOLOG
FTPD JOBNAME FTPD1 ; FTP Server
LPSERVE ; LPD Server
NCPROUT ; NCPRoute Server
PORTMAP JOBNAME PORTMAP1 ; USS Portmap server (SUN 4.0)
RXSERVE ; Remote Execution Server
SMTP ; SMTP Server
OSNMPD ; SNMP Agent Server
SNMPQE ; SNMP Client Address space
TCPIPX25 ; X25
MVSNFS ; Network File System Server
ENDAUTOLOG
The next example shows how to autolog two procedures using the PARMSTRING, DELAYSTART, and JOBNAME options.
S MYPROC1,PARMS='-w 100',ID=XYZ
S MYPROC21,PARMS='-dzy 50',DSN='HLQ.'
AUTOLOG 20
MYPROC1 PARMSTRING "PARMS='-w 100',ID=XYZ" DELAYSTART
MYPROC2 PARMSTRING "PARMS='-dzy 50',DSN='HLQ.'" JOBNAME MYPROC21
MYPROC3 DELAYSTART TTLS
ENDAUTOLOG
PORT 2010 TCP MYPROC1
2011 TCP MYPROC21
2012 TCP MYPROC3
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.