On 04-Dec-2015 07:10 -0600, Bdietz400 wrote:
On Dec 3, 2015, at 8:01 PM, CRPence wrote:
On 03-Dec-2015 16:07 -0600, CRPence wrote:
<<SNIP>> I guess my only concern is why the initial prompt is
taking such a ridiculously long time to appear on v7r1, as
compared to earlier releases.
Wow! Over eight seconds in /wall-clock time/, measured using a
stopwatch, for the prompt to appear after the command line appeared
on the IBM i 7.1 system. On each of the earlier releases I tried,
the appearance is fast enough to be described as /presently/;
effectively, appearing immediately-after the command line appears.
I doubt the configuration on that one system is so ridiculously
different or constrained, as compared with the other systems, so as
to explain that huge delay.
Anyone know, and could share, what I should check to ensure an
appropriate work management setup for starting the BCI job for QSH;
i.e. what I can compare for conspicuous differences, beyond the
following already investigated? The allocation (*ALC) and System
Control (*SYSCTL) system values are near identical, and the maximum
activity levels seem reasonable, the job priorities are equal
[RUNPTY(20)], none are set to utilize prestart jobs [no PJE is
defined for the PGM(QSYS/QP0ZSPWP) nor any environment variable
named QSH_USE_PRESTART_JOBS on any system, so none setup to ensure
the better performance], and all run in the *INTERACT pool... *but*
the QZSHSH job on the v7r1 system seems to remain in a status of
TIMA for an unusually long time, as compared to the other earlier
could the delay be a result of a too low activity level for the
Not according to the statistics presented. Although there are
clearly more threads on the slow system than one of the others, no
systems show any threads going ineligible, and a highball estimate of 7x
threads to activity-level ratio is no worse than the other systems that
do not exhibit a delay. And all of the systems have a 4k to 11k
act->wait, with the slow one at about 6k.
Mark W found the issue documented, with recovery actions [i.e.
resolution], by having searched the web [without using /symptom/
keywords; argh, I was fixated on finding a defect, not a TechNote
document]. Basically the issue is caused by a slow resolution of the
host IP due to some problem with how the Domain Name Server (DNS) is
operating; i.e. modify TCP/IP domain information within the Configure
TCP/IP (CFGTCP) feature [option 10=Work with TCP/IP host table entries
and\or option 12=Change TCP/IP domain information] to ensure a fast
name\IP resolution transpires.
The following web search located the doc at the following URL:
Reference #: N1016223 Historical Number: 329865667
Title: Qshell Session Takes a Long for the Prompt or Time to Start and
"... The Qshell terminal session is displayed, however, the shell is not
ready to accept commands. If the WRKACTJOB is used to display the QZSHSH
job, the call stack shows the gethostbyname() API near the bottom of the
This problem is caused by a Domain Name System (DNS) configuration error
on the system. When the shell starts, it uses the gethostbyname() API to
get the IP address of the local host. It then sets the HOSTID variable
to the IP address. The gethostbyname() API uses the DNS to lookup the IP
address. If the DNS is not configured correctly, gethostbyname() can
block waiting for a response for a DNS server.
Huh. My debugging skills apparently are impaired, a bit rusty,
because I never issued the ever-obvious 10=Program Stack from the
against the QZSHSH job from WRKACTJOB while that job was in TIMA status.
:-( After I realized I could not perform a Start Trace (STRTRC) to
catch the *NEW job, I guess I just gave up, rather than thinking about
what else would accomplish at least some of what I wanted. Perhaps that
is a sign... of something, other than just being a bit rusty ;-)