Re: Survey: STRTCP(*YES) or STRTCP(*NO) in IPL attributes

They should have told the SL rep that their job is to explain the limitation and the location of the documentation about that limit, or to report the problem as a defect to the developers, and not "to suspect" what the design, implementation, or function\outcome should be :-)

What was the supposed "more complex" environment that the failing system had? The only thing I can think of as problematic is that there is a STRTCP request somewhere else, _in addition to_ the STRTCP(*YES), and those are in conflict. Either the autostart options should be defined and effected via the STRTCP(*YES), or the services should be started via the STRTCP, but not both [concurrently]. Seems to me what happened in the failing case was that the STRTCP was probably not removed from QSTRUPPGM, even though the STRTCP(*YES) was established. Thus the advice probably should have been to disable either of the start requests, not to disable one and add another; i.e. another, the STRTCP command, was apparently already there, in order to have given opportunity for the conflict.

FWiW & IIRC, the x/19EF is a Miscellaneous Temporary Space; type *QTSP. Thus it seems odd that there is any locking of the object, or that when there must be, then a very long wait should be enabled to override the DFTWAIT() within the system job, specifically in order to avoid a timeout which would be predictable for likely race conditions between an old QSTRUPPGM having STRTCP and the newer OS having STRTCP(*YES). As a temporary object, there is no ability to use WRKOBJLCK to determine the conflict. Presumably the "resource conflict" was logged as [one of] the MCHxxxx error [e.g. MCH5802] for lock conflicts that was updated to record a job which held a conflicting lock; that would have been investigated from the failing request, which then presumably pointed to the QSYSARB5 system job.

Regards, Chuck

Ingvaldson, Scott wrote:

Someone I know had a resource conflict during STRTCP after a V5R3
--> V5R4 upgrade, the actual problem was apparently the QSYSARB5
job holding a lock on QUSRSYS/QTCPACT of type X'19EF'

One of IBM's recommendations was to "change the IPL attribute
(CHGIPLA) to not start TCP and add a STRTCP to QSTRUP."

From the SL analyst:

"I would suspect the new release has affected the startup timing just enough to cause misc. issues on startup. ...the IPL
attribute is only recommended to be set to start TCP/IP in a very
vanilla environment. If you have anything more complex, which
you do, the recommendation is to not start TCP/IP with the IPL
attribute but rather start it in QSTRUP."

In this day and age does anyone really have a "very vanilla environment?" I spent a lot of time a few years back getting STRTCP(*YES) to work properly so that it wasn't starting twice
and creating miscellaneous server conflicts. I'm curious what
everyone else thinks and does.