Thanks Chuck.
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 QSYS 02D7
QCMD QSYS
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.
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.
Regards,
Scott Ingvaldson
Senior IBM Support Specialist
Midwest Region Data Center
Fiserv.
-----Original Message-----
From: CRPence [mailto:CRPbottle@xxxxxxxxx]
Sent: Tuesday, October 13, 2009 5:53 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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.
midrange.com
