This post reminds me that a key feature of the product under discussion in
the "Was" thread was described as being dependent on "TCP/IP". As always
using the description "TCP/IP" rather than the more precise z/OS
Communications Server IP component - subsequently to be abbreviated as CS
IP - while clearly requiring the IP network layer leaves open the question of
what the transport layer might be. It might be TCP or it might actually be UDP
or - rather unlikely when the emphasis is on some business function as may be
assumed here I think - possibly neither of the standard transport protocol is
to
be used.[1]
If the transport layer is TCP or - a bit curiously - UDP[2], the program under
discussion simply needs to be specified as an entry in both the AUTOLOG
statement list and the PORT statement list[3].
The consequences of this can be noted from these references:
>From the CS IP Configuration Guide:
<quote>
1.5.3.4 Setting up reserved port number definitions in PROFILE.TCPIP
...
AUTOLOG
Use AUTOLOG to list the procedure names that should start when the TCPIP
address space starts. It is also used to supply a timeout value for detecting
hung procedures at TCP/IP initialization time. The timeout value is 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. A hung
procedure is active to MVS, but is not listening on the socket that is reserved
for it via the PORT statement. When AUTOLOG detects a hung task, TCP/IP
checks every 10 seconds (until the timeout value has expired) to see 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 the timeout value expires, then TCP/IP cancels and
restarts the procedure.
The AUTOLOG statement shown in Figure 35 has a timeout value of five
minutes.
In the first AUTOLOG statement the FTP Server shows FTPD JOBNAME FTPD1.
This means when the TCPIP address space starts, the FTPD procedure will be
started via the MVS START FTPD command. Because FTPD forks a child
process that actually listens on PORT 21, the autolog task verifies that FTPD1
is listening on port 21.
Similarly, when the TCPIP address space starts, the autolog task starts the
remaining 10 tasks.
Unless the tasks in the AUTOLOG list are in the PORT reservation list, the
autolog task does not check for hung tasks every five minutes.
...
</quote>
And confirmation about starting with the main CS IP address space.
<quote>
1.2.22.8 Step 6: Start the TCP/IP address space
Enter the MVS START command from the operator's console to start TCP/IP,
specifying the member name of your cataloged procedure. This will start the
TCP/IP address space and any of the servers you have defined in the
AUTOLOG statement in PROFILE.TCPIP. For example, if the procedure to start
the TCP/IP address space was called TCP1 in your PROCLIB, you would enter:
START TCP1
For information on updating the TCPIP cataloged procedure or configuration
statements used to configure the TCPIP address space, see z/OS
Communications Server: IP Configuration Reference.
</quote>
I had to go to Chapter 26 out of 33 down the table of contents before I found
an old-fashioned "server" described which described the use of the AUTOLOG
function in its simple original role, hence the reference to LPD.
<quote>
2.17.1.1 Step 1: Configuring PROFILE.TCPIP for LPD
If you want the LPD server started automatically when the TCPIP address
space is started, include the name of the member containing the LPD server
cataloged procedure in the AUTOLOG list in hlq.PROFILE.TCPIP. For example:
AUTOLOG
LPSERVE
ENDAUTOLOG
To ensure that port TCP 515 is reserved for the LPD server, also add the name
of the member containing the LPD cataloged procedure to the PORT statement
in hlq.PROFILE.TCPIP. For example:
PORT
515 TCP LPSERVE
See the z/OS Communications Server: IP Configuration Reference for more
information about the AUTOLOG and PORT statements.
</quote>
Why I was reminded of needing to place some stress on the use of the
AUTOLOG function was the fact that the main CS IP address space is quite
happy to use the CANCEL command to dispose of an errant address space
whenever it feels it needs to - which might put some of this "CANCEL"
discussion in perspective.
Chris Mason
[1] There is a post on the IBMTCP-L list from the same original poster which
indicates we may be dealing with TCP here - CONNECT is mentioned - but it's
not definite of course.
[2] The problem I have with UDP in the context of the AUTOLOG function is
that, while the "listening" condition is a permanent feature of the TCP
protocol
when it is ready for work, in what I assume to be a typical UDP program there
exist "windows" of time when there may not be an outstanding "read"-like call
in place which I believe is what is regarded as the "listening" condition in
the
case of UDP. I would be nervous that the AUTOLOG "listening" test just might
be performed in those "windows" of time after a "read"-type call has been
satisfied and the next "read"-like call hasn't quite yet been reached.
[3] Assuming we are dealing with a service supported by TCP or UDP running
in a CS IP environment, the relevant port number needs to be associated in
the PORT statement list with a BIND parameter defining a VIPA as being the
most usual way to dissociate the service from individual fallible "hardware"
interfaces. I trust the documentation will at least allude to the principle
behind
this consideration. I didn't notice this in Linda Mooney's extensive list.
On Thu, 30 Sep 2010 16:13:11 -0400, Robert A. Rosenberg
<[email protected]> wrote:
>At 10:04 -0500 on 09/29/2010, Tom Marchant wrote about Re: Really
>dumb IPL question:
>
>>On Tue, 28 Sep 2010 22:26:29 -0400, Robert A. Rosenberg wrote:
>>
>>>Shutting down a Started Task can be done in the way other STCs are
>>>controlled. ... you can just use the Modify (F) or STOP (P)
>>>command . If MODIFY is good enough for TCP, TSO, etc, it should be
>> >good enough for your RYO STC. It sounds like those Ops/Automation
>> >types are brain dead and do not understand what they are doing.
>>
>>MODIFY and STOP only work if the code is written to recognize them.
>>Some products are not coded to work with a STOP command. If not,
>>it is not the automation that is brain dead.
>>
>
>The assumption of my comment was the program was written to use STOP
>or MODIFY to signal the task to terminate. The quote that I was
>responding to (which was omitted from your reply) was to the effect
>that it was against the Ops/Automation types rules/procedures to use
>CANCEL (or STOP/MODIFY which use the same QEDIT interface) to signal
>the terminate order. We are not taking about pulling the rug out from
>under the task via FORCE here by sending a request for an orderly
>shutdown using standard interfaces. Note that I may be wrong about
>the ability to intercept the CANCEL and suppress it since you are
>going to do an orderly shutdown by treating as a STOP.
>
>The quote was:
>
>>Setting this up as a started task and then explaining to
>>Ops/Automation that the only way to stop it was to Cancel the
>>Started task was not fun (against their operational procedures) ....
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
