Re: GREP doesn't work

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
releases.

<<SNIP>>

could the delay be a result of a too low activity level for the
subsystem?

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:
[https://www.google.com/search?q=ibm+i+7.1+qshell+takes+a+long+time+to+show+%24+prompt]

[http://www.ibm.com/support/docview.wss?uid=nas8N1016223]
Reference #: N1016223 Historical Number: 329865667
Title: Qshell Session Takes a Long for the Prompt or Time to Start and Run Commands
"... 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 stack.

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 ;-)