× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.