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

elehti@xxxxxxxxxxxxxxxxxx wrote:

Have you experienced the STRSQL "Slowness Gremlin"?
<<SNIP>>

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 <<SNIP>>

FWiW the B[ottom] going instantly to the bottom has been a feature from the beginning from what I can recall from what was provided by the Query/400 run-time report writer extended to the STRSQL. It is activated by the refresh option.

The STRSQL has various options that can affect the query requests. There is the optimization rule for data [copy] retrieval and two data retrieval settings. The former, /allow copy data/ suggests whether temporary data can be used. The latter enables /live data/ [within buffer bounds] or Live Forward Only data. Check the REFRESH() in the F13=Services, and ensure these settings are consistent between sessions. Additionally the CONNECT must both be local for comparison; the report writer for non-local connections is not the same as for local.

Ensure the COMMIT() is the same between sessions, or add FOR READ ONLY WITH NC to the SELECT.

Note that a huge issue with interactive reporting and messaging by the database engine about the processed\selected rows is the 5250 asynchronous messaging. Avoid the condition by issuing a CHGJOB STSMSGS(*NONE). Then even if the path that is chosen results in those messages, the messaging will have almost no noticeable impact.

Finally there is the possibility that the query implementation is CQE in one [e.g. the one with many messages] and SQE in the other, where the lack of messages allows unimpeded presentation. The SRTSEQ and LANGID settings could affect the results for which engine is utilized.

Regards, Chuck