Re: How does TCPIP start on a 7.1 system?

Why not use an API to inquire of [and poll on] the "Interface status" to see if the required service has been started, before invoking a feature that depends on the status having transitioned to /active/ from inactive or starting? Sure seems better than hard-coding a two-minute wait which could either be excessively long or perhaps merely momentarily too short, to allow the required service to become available. Doing that, whether the TCP/IP is started by CHGIPLA or by the startup program becomes irrelevant. Of course if the Start TCP/IP Server (STRTCPSVR) offered a synchronous wait option to await the confirmation of the start of the server [probably with a timeout error allowing the request to effectively give-up], then the next request could be coded assuming that its dependency on the prior start-command has completed. Does the following API not enable that?:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qtocrtvnetifcdta.htm
Retrieve Network Interface Data (QtocRtvNetIfcDta)

That is what I have similarly effectively questioned by my lambasting of recommendations shown to originate from IBM for similar hard-coding of wait times pending the ending of work in preparation for save activity; e.g. waits of five minutes coded, as described in [and in links found in] the following message:
Subject: Re: TCP/IP starts twice in V7
http://archive.midrange.com/midrange-l/201209/msg00790.html

Regarding that KB item linked in the message quoted below...
Is it really so difficult for the OS processing of the STRTCP command itself to inquire of the system whether the other possibly conflicting work is already done, such that the request can safely continue, rather than creating a document that recommends customers add a hard-coded three-minute delay before issuing the STRTCP command? If that feature can not ask the correct questions of its underlying support to know when it may safely continue [to start], then why can not that feature itself calculate the time since "the IPL" and delay until 180 seconds after that point... given that wait time is the recommendation? Why offload that burden onto everyone who administers their system.

I am shocked at what crap some people will put up with, when they are so eager to complain about other things that seem to me like nits :-)

Regards, Chuck

On 19 Apr 2013 04:44, rob@xxxxxxxxx wrote:

On 19 Apr 2013 06:01, rob@xxxxxxxxx wrote:

I see that my startup program does a two minute delay after
starting QSYSWRK to give TCP/IP some time to start. So I think I
can just do the starting/stopping of the change management server
in my switch programs without ramifications.

I appreciate everyone digging into this.

What I am trying to do is start a web based part of my change
management package. Putting that into the startup program, when
TCP/IP may not be started yet, is probably not a good idea.

And my H/A switch programs are also executed by the startup program
(there's a lot of switches and stuff in there that I don't want to go
into detail about). As part of my switch it is recommended that I
stop/start the change management packages web based part. I could
easily change the switch programs, but if they're also called by the
start up program, and tcp/ip is not yet active, well, I don't expect
success.

http://www.ibm.com/support/docview.wss?uid=nas1984881498987e7d0862572fe00646103

Thinking as I type...
Isn't there some way to add your own TCP/IP application? That might
be IBM's new dogma. I'll look into that. Found it, ADDTCPSVR. So
let's say my change management vendor has a command called ICTLSVR.
And that command has one parameter, *START or *STOP. So I write a
wrapper that follows the help on ADDTCPSVR and executes that command.
That "may" work.
Providing that, if http needs to be running tcp starts that server
before starting my new one.
I still have my switch issue. If I put that command into my switch
programs, or use END/STR_TCPSVR ICTLSVR, and my switch programs are
called by the startup program, arrgh!!!

So is it really a puck to the teeth if I do a CHGIPLA and remove the
start of tcp/ip and put STRTCP back into the startup programs?

Would that change to CHGIPLA be permanent, unlike CHGIPLA
STRRSTD(*YES) which only lasts one IPL? Well, I do notice that
STRRSTD says "This attribute is reset to its initial value after each
IPL." while the STRTCP parameter does not.

Would it really do any good to move it back to the startup program?
Meaning, since TCP will be separate tasks wouldn't I have to wait
until it's up enough to do anything?