Try setting the virtual memory paging file size on your PC's to a custom
size vs the "system managed size" that is the default. I've had the best
luck setting the initial size and the maximum size to the same value. I
usually set this to around twice the actual memory on the machine.
Some IBM PC software works much better this way and this includes the
5250 emulator.
Pure (educated?) speculation on my part, but I think this is the reason:
Many of the PC programs IBM distributes are based on code that was
originally developed for OS/2. These programs allocate memory using OS/2
techniques rather than using Windows API's to allocate memory. Windows
often chooses to "move" memory to another virtual address space. If the
memory has been allocated using the Windows API's, the OS has a record
of the allocation and can move it readily. If not, the application
breaks or waits until a memory allocation error is resolved through some
kind of virtual memory scan. When you set the virtual memory paging size
as I suggest, you eliminate or reduce the problem because Windows
fiddles with virtual memory far less often.
The 5250 emulator is less susceptible to this problem than other IBM
software as it doesn't allocate memory very often.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
elehti@xxxxxxxxxxxxxxxxxx
Sent: Thursday, May 07, 2009 9:52 AM
To: midrange-l@xxxxxxxxxxxx
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.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
