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

Eric Lehti

VIP Member
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.
 
Re: STRSQL \"Slowness Gremlin\" infecting 5250 Session B, or Session C, or Session A

fb,
A couple of suggestions:

Can you check the sort sequence on each SQL session? Take F13 from the SQL window, page down and the sort sequence should be *HEX. Some people were using sort sequence= *LANGIDSHR but only for some sessions - *LANGIDSHR this is nice in that it makes your SQL statement case-insensitive but it also can increase the time of your SQL statements.

Also, check the access path size on the files you are querying. It should be set to MAX*1TB to increase the index size. We had some sporadic performance issues a while ago and it helped greatly.

May not be directly related to your issues, but worth a try I guess.
 
Re: STRSQL \"Slowness Gremlin\" infecting 5250 Session B, or Session C, or Session A

Mark, I thank you because you pointed me in the right direction. I discovered that SQL slowness was due to Session Attribute (F13 key) Data Refresh parameter being set to *FORWARD instead of *ALWAYS. The help text for *FORWARD says, The results of a SELECT statement are written to a
temporary file as you page forward. As you page
backward, data that already has been shown is
displayed again and the SELECT is not reprocessed.
Instead, the data is displayed from the temporary
file. This option does not show any changes to a row
(record), made by another user, after it has been
displayed the first time. However, the response time
is typically faster using this option.
 
Back
Top