RE: STRSQL "Slowness Gremlin" infecting 5250 Session B, or Session C, or Session A

Based on the messages you've listed, I am pretty sure it has nothing to do
with Client Access or STRSQL. You just happen to be hitting CQE in the
'slow' case and not others.
What could cause Query Dispatcher to route the query to CQE? There are a
number of reasons and Visual Explain would help you there. To make Visual
Explain meaningful, you're probably best off collecting DBMON data on your
'slow' interactive job and then importing it into Navigator's SQL
Performance Monitors. Then use Visual Explain off of it.
First thing I'd check is environmental settings in STRSQL, which you can see
by hitting F13. What's SRTSEQ set to (if not *HEX, there's probably
translation going on, causing a reroute to CQE [pre-V6R1]). ALWCPYDTA may
come into play, but not so sure about that one. Then there is the 'Data
refresh' setting, but I've never played with that one.
Finally, is the 'slow' query using UPPER or LOWER and you're on a pre-V6R1
machine? This could cause the CQE reroute. Again, Visual Explain would
give you more info.

Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com


-----Original Message-----
Subject: STRSQL "Slowness Gremlin" infecting 5250 Session B, or Session C,
or Session A

Have you experienced the STRSQL "Slowness Gremlin"?
I am the System i administrator here with QSECOFR authority.
On my PC I have the latest IBM iSeries Access for Windows Version 5
Release 4 Modification level 0, Service Level PTF SI32972, connected to
a System i 9406 model 520 running V5R3.
I have STRSQL "Slowness Gremlin" on one of my six 5250 sessions each day
that always infects ONE of my six 5250 sessions.

Sometimes the STRSQL "Slowness Gremlin" is on 5250 Session A.
Sometimes the STRSQL "Slowness Gremlin" is on Session B.
Sometimes the STRSQL "Slowness Gremlin" is on Session B.

When I STRSQL and do a SELECT * from [a file with millions of records),
and then put a 'B' in the Position to line field to get to the bottom of
the file, 5250 sessions will instantly go to the Bottom of the file (per
the IBM SQL enhancement circa 1995) But whatever session is infected
with the "Slowness Gremlin" will require 5-to 9 minutes to get to the
bottom of the file. During those several minutes a message at the
bottom of the screen will display the progress:

Query running. 738198 records selected, 1476413 processed.
Query running. 839118 records selected, 1678253 processed.
Query running. 891088 records selected, 1782193 processed.
Query running. 973636 records selected, 1947289 processed.
Query running. 1052216 records selected, 2104449 processed.
Query running. 1167446 records selected, 2334909 processed.
And finally it gets to the bottom of the file and displays ******** end
of data **********


I have tried with no success to replicate this problem on two other PCs
by starting six 5250 sessions and doing six STRSQL. Neither of those
machines exhibits the "Slowness Gremlin".

IBM tech support recommended first that I get current on PTF (as
described above). Next IBM recommendation is shown below.
IBM Software Technical Document Number: 452257168
Document Title:Instructions for Collecting a User Dump of a Windows
Process Document Description:
There are times when a Microsoft Windows process that is using IBM
iSeries Access technologies can become hung or unresponsive. In some of
these cases, the available client traces are insufficient to determine
what piece of software is "stuck," and a user dump of the process is
required.
The following steps are required to collect a process dump on a Windows
PC.