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

[CRPence <CRPbottle@xxxxxxxxx>]

  Comments inline.

Regards, Chuck

Ingvaldson, Scott wrote:
> I'm pretty sure (but not positive) that there was no STRTCP
> in his QSTRUP at the time. 
>
> This is the message he reported:
>
> TCP1A1F  50 10/05/09  21:21:34.084376  QTOCTCIX   02D7   QCMD 
>   Message: Cannot process request while 059773/QSYS/QSYSARB5
>            using QTCPACT.
>   Cause:   The requested function cannot be performed while job
>            059773/QSYS/QSYSARB5 is using object QUSRSYS/QTCPACT
>            of type X'19EF'.
>            An attempt to allocate QUSRSYS/QTCPACT failed after
>            waiting 30 seconds.   
>   Recovery:  Do one of the following and then try the request
>            again.      
>           - Wait until job 059773/QSYS/QSYSARB5 is not using
>            QUSRSYS/QTCPACT.
>           - Use the command ENDJOB JOB(059773/QSYS/QSYSARB5)
>           OPTION(*IMMED) to end job 059773/QSYS/QSYSARB5.
>              If the problem persists, use the Analyze Problem 
>           (ANZPRB) command to report it.

  That error seems likely to be from a different job than what I 
inferred from the OP.  That error seems to indicate the timeout was 
recorded in some job other than QSYSARB5.  The job name was not 
included as part of the snippet of the joblog quoted below.  If the 
snippet is from the QSYSARB5 joblog itself, then the thread 
information should have appeared for each message, because a lock 
can not truly conflict with a lock held in the same job except when 
thread-scoped.

  So if the above joblog snippet is not from QSYSARB5, then from 
what job, and what was the failing request?  I suppose as part of 
STRTCP(*YES), then that may have been in the SCPF [i.e. Start CPF, 
IPL] joblog?

> I wonder if this wasn't the problem:
>
> > From SKB Document Number: 454746342
>
> There are several things to be aware of when configuring and 
> attaching a 3494 tape media library to the system via TCP/IP for 
> V5R2M0 and above.
>
> When the system is ended to a restricted state, TCP/IP is ended. 
> When a save or backup job then tries to use the 3494, the code 
> detects that TCP/IP was ended and it starts TCP/IP in restricted 
> mode. After this occurs and if later a PWRDWNSYS with Restart 
> type *IPLA is run, TCP/IP will fail to start. In this case, users
> should issue the ENDTCP command before powering the system down.
>
> When a 3494 is configured to use TCP/IP, users should ensure that
> the 3494 device configuration will not vary on at IPL. What 
> happens is the 3494 tape device might vary on before the STRTCP 
> occurs. In this case, TCP/IP starts as if the machine were in 
> restricted mode: STRTCP STRSVR(*NO) STRIFC(*NO) STRPTPPRF(*NO). 
> When the IPL process starts TCP/IP, the STRTCP command fails with
> the message TCP/IP already active.

  That would seem a reasonable conclusion if there is such a device 
effecting both the automatic post-IPL varyon and the noted [or a 
similar] TCP autostart.  However for that, I would have expected the 
advice by SL should have been to add ENDTCP before a STRTCP in the 
QSTRUP [i.e. not just the latter], or instead, both to change the 
device to ONLINE(*NO) and to issue a VRYCFG STATUS(*ON) only after 
the STRTCP in the QSTRUPPGM.

Regards, Chuck