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

[CRPence <CRPbottle@xxxxxxxxx>]

  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.