IPL, TCP & starting socket-based servers in QSTRUP

[Mr. K.V.B.L.]

I know that if one checks CHGIPLA you can see if TCP is started at IPL (STRTCP(*YES)).

1. When exactly is TCP started? Before or after the QSTRUP program has started?

I want to start a group of TCP socket servers in the startup program, but when I do they all fail for a certain amount of time with the following error message:

"The TCP/IP routine accept() failed because of The protocol required to support the specified address family is not available at this time."

I'm reading through old posts about STRTCP and it seems that TCP is reliant on the subsystem QSERVER being fully functional. That is fine, I just need to know when to start my jobs to avoid these log file messages. The log file grows to a huge size while this TCP/QSERVER initialization is taking place.

[Ad]

Starting TCP - Using the IPL Attributes Versus the System Startup program
http://www-01.ibm.com/support/docview.wss?rs=0&context=SGYQGH&q1=qstrup&uid=nas8N1014291&loc=en&cs=utf-8&lang=

When I have no additional things to start in QSTRUP I use CHGIPLA
STRTCP(*YES)
otherwise I allways use STRTCP in QSTRUP with a delay.

Ad.

[CRPence]

On 29-Oct-2013 14:33 -0700, Mr. K.V.B.L. wrote:
> I know that if one checks CHGIPLA you can see if TCP is started at
> IPL (STRTCP(*YES)).

That shows if the IPL attribute will effect STRTCP at\near the
completion of the OS IPL processing. From older releases, the
implication of that IPL Attr setting is that the "STRTCP command is
automatically submitted at the completion of IPL"; actually or
effectively /submitted/ is, as I recall, dependent upon release. For
example, I think since v6r1 the request was effected in the QSYSARB5 [or
some other QSYSARB#] system job; thus /activated/ in a system job, but
not effected by an actual "Submit Job (SBMJOB)" request, as one might
infer from that text.

In v7r1 the docs suggest the "Start TCP/IP (STRTCP)" parameter
"Specifies whether the Start TCP/IP (STRTCP) command is automatically
submitted at the completion of IPL and when the controlling subsystem is
restarted to bring the system out of the restricted state. The STRTCP
command is not submitted during install IPLs or when the system is
starting to the restricted state."

> 1. When exactly is TCP started? Before or after the QSTRUP program
> has started?

The final step in the OS IPL is effectively, starting (STRSBS) of the
controlling subsystem (QCTLSBSD system value); i.e. the final action for
which the OS IPL transfers control to the user-defined continuation of
the IPL [auto-start and start-up activity]. Preceding the start of the
controlling subsystem, is the start of all /system jobs/ of which one
will be the QSYSARB# job; a job that may, according to the STRTCP IPL
Attribute, Start the TCP/IP interfaces and servers. From the above
quoted v7r1 CHGIPLA command help text, they should be considered to be
started concurrently, because although they may be started serially,
each start request [the autostart job entry QSTRUPJD in the controlling
subsystem and the STRTCP command] will runs asynchronous to their
original method of activation that were likely performed serially.

> I want to start a group of TCP socket servers in the startup program,
> but when I do they all fail for a certain amount of time with the
> following error message:
>
> "The TCP/IP routine accept() failed because of The protocol required
> to support the specified address family is not available at this
> time."

I expect that defining and using a user-defined TCP/IP server with
the AutoStart attribute set to *YES might be a better approach? Look at
the Add TCP/IP Server (ADDTCPSVR) command.

Or possibly... Just test\poll an "interface status" [i.e. ensuring
"Active - The interface has been started and is running."] or test\poll
the pre-requisite "stack status" [i.e. ensuring either "Active - The
TCP/IPv4 stack is operational." or "Active - The TCP/IPv4 stack is
operational."] before trying to start the socket servers that require
the protocol having been established.?

> I'm reading through old posts about STRTCP and it seems that TCP is
> reliant on the subsystem QSERVER being fully functional.

Not sure where that was implied, but that seems amiss. AFaIK, the
QSYSWRK *SBSD would be the more likely to have TCP/IP server jobs; e.g.
from older releases anyhow, the QTCPIP and QTCPMONITR type-BCH jobs, and
various other jobs running\started with user QTCP.

> That is fine, I just need to know when to start my jobs to avoid
> these log file messages. The log file grows to a huge size while
> this TCP/QSERVER initialization is taking place.

Not sure about the origin for the log file growth, but from that
description I infer perhaps the code just loops repeatedly without any
delay to retry the failure? That would mean tempering the retry by
coding a timed-wait could reduce the errors being logged?

Regardless... Back to the "when to start"... Perhaps like I alluded
earlier, to offloading the start to the STRTCP itself, irrespective the
initiation being effected by STRTCP [e.g. in the QSTRUPPGM] or effected
via the IPL attribute the CHGIPLA. Or if that does not make sense, then
perhaps polling for an /active/ status of the pre-requisite function,
either within the StartUp program or within the jobs that are the
/socket servers/ that are activated by the startup program.

--
Regards, Chuck

[CRPence]

On 24-Nov-2013 13:41 -0800, CRPence wrote:
> On 29-Oct-2013 14:33 -0700, Mr. K.V.B.L. wrote:
>> I know that if one checks CHGIPLA you can see if TCP is started at
>> IPL (STRTCP(*YES)).
>
> That shows if the IPL attribute will effect STRTCP at\near the
> completion of the OS IPL processing. From older releases, the
> implication of that IPL Attr setting is that the "STRTCP command is
> automatically submitted at the completion of IPL"; actually or
> effectively /submitted/ is, as I recall, dependent upon release.
> For example, I think since v6r1 the request was effected in the
> QSYSARB5 [or some other QSYSARB#] system job; thus /activated/ in a
> system job, but not effected by an actual "Submit Job (SBMJOB)"
> request, as one might infer from that text.
>
> In v7r1 the docs suggest the "Start TCP/IP (STRTCP)" parameter
> "Specifies whether the Start TCP/IP (STRTCP) command is automatically
> submitted at the completion of IPL and when the controlling subsystem
> is restarted to bring the system out of the restricted state. The
> STRTCP command is not submitted during install IPLs or when the
> system is starting to the restricted state."
>

> <<SNIP>>

I finally found a prior discussion in which I participated. That
discussion "How does TCPIP start on a 7.1 system?" tried to clarify some
of the IBM i 7.1 function for that IPL Attribute setting. Easiest to
read the following message using the _fixed_ feature that appears as a
link in the upper-right of the page, and that can be clicked to reformat
the text; although the trailing hash character seems apparently to imply
that the fixed-font formatting is the desired effect, my experience is
that the effect comes only from actually clicking the _fixed_ on a page.
The link to that message:
http://archive.midrange.com/midrange-l/201304/msg01248.html#

Essentially that message suggests that the job *N/QSYS/QSYSARB4
issued a SBMJOB CMD(QSYS/STRTCP) JOBQ(QSYS/QSYSNOMAX)
JOBD(QSYS/QTOCSTRTCP) USER(QPGMR) JOB(QSTRTCP) [possibly USER(*JOBD)]
for which the job *N/QPGMR/QSTRTCP will have initiated the start of the
TCP/IP interfaces and servers [according to the parameter defaults for
the *LIBL/STRTCP command, as I infer] instead of the STRTCP being issued
within the QSYSARB# job itself.

FWiW, A link to the message thread:
http://archive.midrange.com/midrange-l/201304/threads.html#00956

> <<SNIP>>

> Or possibly... Just test\poll an "interface status" [i.e. ensuring
> "Active - The interface has been started and is running."] or
> test\poll the pre-requisite "stack status" [i.e. ensuring either
> "Active - The TCP/IPv4 stack is operational." or "Active - The
> TCP/IPv4 stack is operational."] before trying to start the socket
> servers that require the protocol having been established.?

I failed to include the doc links for the above quoted comments. The
following two APIs, from Service Program QTOCNETSTS, are documented to
provide the above quoted information; quoted from the following doc links:

http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qtocrtvnetifcdta.htm
"... The Retrieve Network Interface Data (QtocRtvNetIfcDta) API
retrieves detailed information about a specified IPv4 or IPv6 network
interface.

TCP/IP stack must not necessarily be active for this API to be called.
..."

http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qtocrtvtcpa.htm
"... The Retrieve TCP/IP Attributes (QtocRtvTCPA) API retrieves TCP/IPv4
and TCP/IPv6 stack attributes. ..."

--
Regards, Chuck

[Dr.UgoGagliardelli]

You've the chance to wrap your servers in an user-defined server
specifyng to start when TCP starts, using ADDTCPSVR AUTOSTART(*YES)
command, where PGM must be a program with the proper interface. This
program should return as asap, because it's called synchronously by
starttcp job, maybe submitting a further batch job.
However, when a socket starts, even if called by startcp, should verify
that needed protocols are available, maybe looping until errno=0.
Infact, even if started previously, a network takes time to become
active. It must wait that the process to vary on lines, devices and
interfaces competes.