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-01.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?
Rob Berendt
midrange.com
