Programs loading slowly

Several of our fat clients on OneWorld Xe Update 6 SP20 have the following problem: With applications which they use often (an example is the P0006), sometimes when they start the app, the screen goes grey for about 15 seconds and then the app starts. When they start the app again, it starts fine. If they don't work with the app for a while on the same day they get the same behavior again.

There isn't a JITI-- I mean the user enters the application every day, and the first time it's slow, the next time it's fast, and then if he doesn't use it for a while it's slow again.

I noticed that in the case of two users, this behavior happened when they started oneworld and then a packages was deployed *while they were connected* (not I say deployed, not installed). When we accepted the package, the problem seemed to go away. However, the user says that this happens even if there are no packages pending.

We tried changing the JDE.INI in the client to make "CACHE_UseCache=0" instead of 1. This seemed to effect absolutely nothing.

The client tells me that it happens with all apps, not just a few.

Has anyone seen something like this? Is there a fix? Thanks in advance.

Tim,
One World does cache applications.
I know this occurs because when making changes to apps I need to log off and log back on so the new copy of the app is utilized.
This may be what you are seeing.
Regards,
Dave

Tim,
I have seen similar behavior at two clients of ours always when the deployment server was turned off. We never really found out why, but we suspect the mapping to media objects.

Gerd

Which OS are the clients using?





Looking for work out west
Daniel Bohner | JDE P/A III | Freelance-JDE/Web/Photo
www.ExistingLight.Net | www.ExtremeSights.com | [email protected]
JDE XE | SP20 | AS/400 | V5R1

Check that the deployment is not in use when you have this problem.




timallen
<jdelist@timallen To: [email protected]
.org> cc:
Sent by: Subject: Programs loading slowly
jdelist-bounces@j
delist.com


04/11/2003 14:51
Please respond to
"JDELIST One
World / XE
Discussions"






Several of our fat clients on OneWorld Xe Update 6 SP20 have the following
problem: With applications which they use often (an example is the P0006),
sometimes when they start the app, the screen goes grey for about 15
seconds and then the app starts. When they start the app again, it starts
fine. If they don't work with the app for a while on the same day they get
the same behavior again.

There isn't a JITI-- I mean the user enters the application every day, and
the first time it's slow, the next time it's fast, and then if he doesn't
use it for a while it's slow again.

I noticed that in the case of two users, this behavior happened when they
started oneworld and then a packages was deployed *while they were
connected* (not I say deployed, not installed). When we accepted the
package, the problem seemed to go away. However, the user says that this
happens even if there are no packages pending.

We tried changing the JDE.INI in the client to make "CACHE_UseCache=0" in!
stead of 1. This seemed to effect absolutely nothing.

The client tells me that it happens with all apps, not just a few.

Has anyone seen something like this? Is there a fix? Thanks in advance.
--
Tim Allen, (JDE Jedi Master) Barcelona
Xe, ES/DS Windows 2K, Oracle 8.1.7/SQL Server
http://www.javajunkies.org
To view this thread, go to: http://www.jdelist.com/ubb/showthreaded.php?Cat
=&Board=OW&Number=63563

This is the JDELIST One World / XE Mailing List. To stop receiving these
messages, login to http://www.jdelist.com/forums, click Control Panel,
then click Edit by "Subscribe / Unsubscribe from receiving board posts by
email, change message notifications, etc." and adjust your subscription
preferences. JDEList is not affiliated with JDEdwards®

More info:
I was able to repeat the behavior with logging on. Here is the bit that is slow:

15:41:32 RT: >>>Beginning ER: Control is Entered App: Form: W09200A [T:75c F:\b7\system\jdeuser\jdecgrt\RT_ER.cpp Ln:2961 Lv:LEVEL3]

15:41:32 RT: <<<Finished ER: Control is Entered App: Form: W09200A :: [T:75c F:\b7\system\jdeuser\jdecgrt\RT_ER.cpp Ln:2985 Lv:LEVEL3]

15:41:32 Entering GetUserProfileCache
15:41:32 GetUserProfileCache returns the value from ghEnv
15:41:32 Entering GetUserProfileCache
15:41:32 GetUserProfileCache returns the value from ghEnv
15:41:32 Entering GetUserProfileCache
15:41:32 GetUserProfileCache returns the value from ghEnv
15:41:32 Entering GetUserProfileCache
15:41:32 GetUserProfileCache returns the value from ghEnv
15:41:32 Entering GetUserProfileCache
15:41:32 GetUserProfileCache returns the value from ghEnv
15:41:45 Entering JDB_FreeUser

NOTE that the very last entry in in this extract is 13 seconds after its predecessor.

I can't find anything in the log that explains what it is trying to do during these 13 seconds.

Also I don't understand why it is calling GetUserProfileCache when I have "CACHE_UseCache=0" in JDE.INI (But I also don't know if this parameter controls caching or not, it's really just a guess).

One thing: I opened the P98moque (Media Object Queues), and I seem to remember that there is supposed to be a mapping for HELPS, but I find none. What is the name of this entry normally? If this mapping should exist and I don't have it, could this possibly cause the problem?

UPDATE: Forget this about the helps. It's in the JDE.INI (ServerHelpPath=\\DEPSVR\B7333\Helps), and the mapping is correct for these users.

Thanks in advance.

By the way, the deployment server is on and running fine when this happens.

Three suggestions of things to check:
1 Windows XP system restore
2 Virus Scanning
3 IPX running on your fat clients
Regards
Kieran Fitzgerald

Someone still uses IPX??? WOW... and I thought I couldn't barge the old
horse...

If IPX is running - it would be an issue.

db




Looking for work out west
Daniel Bohner | JDE P/A III | Freelance-JDE/Web/Photo
www.ExistingLight.Net | www.ExtremeSights.com | [email protected]
JDE XE | SP20 | AS/400 | V5R1

Tim,

What was the conclusion?

Did you find out what was going on ?

We have the same situation here and it will be good if you have any tips on it.

Hello Tim Allen,
we have the same problems on our XP and Win2K fat clients and terminal servers.
First we thought it's only happenening on terminal servers but this was a wrong suspicion.
We've been in contact with JDE support for weeks (almost months) - no help.
As this issue happens more often to normal users than to administrators we thought there may be a permission/security issue. Among other things we gave full permission on the registry to the users (just for tesing purposes) and since then the issue occurs very rarely!
PLease let me know if you make any progress in this issue.

By the way: in our environment the delay is 48 seconds (not 13)

Regards

Okay, more stuff. The clients are on Windows 2000.

Here are my theories-- we have some clients that this never happens to. They all seem to have a drive mapped to the b7333 directory on the deployment server.

So what I'm trying is this: map a drive to the deployment on a client with this problem. I'll see if the client responds. My theory is that if the client does not have the drive mapped, Oneworld finds the D/S via the name of the D/S. This name resolution must takle some time. After that, the user has the name resolved for a while, but this must time out after a while.

Does this sound correct? Oh yeah, they have Novell NetWare here.

Why don't you try to update the local hosts file with the machine names JDE
could need?




timallen
<jdelist@timallen To: [email protected]
.org> cc:
Sent by: Subject: Re: Programs loading slowly
jdelist-bounces@j
delist.com


05/11/2003 11:03
Please respond to
"JDELIST One
World / XE
Discussions"






Okay, more stuff. The clients are on Windows 2000.

Here are my theories-- we have some clients that this never happens to.
They all seem to have a drive mapped to the b7333 directory on the
deployment server.

So what I'm trying is this: map a drive to the deployment on a client with
this problem. I'll see if the client responds. My theory is that if the
client does not have the drive mapped, Oneworld finds the D/S via the name
of the D/S. This name resolution must takle some time. After that, the
user has the name resolved for a while, but this must time out after a
while.

Does this sound correct? Oh yeah, they have Novell NetWare here.
--
Tim Allen, (JDE Jedi Master) Barcelona
Xe, ES/DS Windows 2K, Oracle 8.1.7/SQL Server
http://www.javajunkies.org
To view this thread, go to: http://www.jdelist.com/ubb/showthreaded.php?Cat
=&Board=OW&Number=63651

This is the JDELIST One World / XE Mailing List. To stop receiving these
messages, login to http://www.jdelist.com/forums, click Control Panel,
then click Edit by "Subscribe / Unsubscribe from receiving board posts by
email, change message notifications, etc." and adjust your subscription
preferences. JDEList is not affiliated with JDEdwards®

If they have novell, are they using IPX for connectivity on the clients? If
so, there is a setting that appears to improve the performance of accessing
shares on windows servers. Network and dial up connections - advanced -
advanced settings - highlight your network card in connections and change the
binding order for client for Microsoft networks, and file and print sharing
to us IP first.
Another thought, if they are using the awful novell client, then when you map
a drive from a client to the b7333 share on the deployment, are they getting
prompted for a username/password?
And another thing, are you using solution explorer on these clients?
Regards,
Kieran Fitzgerald

Hi Tim,

I won't not map a drive to the deployment server (that is one way for virus to infect your deployment server).

If it is DSN problem, simply add the IP of the Deployment server and Enterprise Server to the Host table on the PC. c:\winnt\system32\drivers\etc\host. A PC will always check the host file first for an address. I have had to do that at one place because they were have WINS and DNS problens.

Also make sure the data sources are set for TCP/IP and no named pipes. I have seen this cause degredation in performance also.

dfaryniuk,

I had this same problem when we first upgraded to V5R2 because certain system settings can be lost in an upgrade, etc. Here are some steps I went through to fix the issue:

1) Make sure you are using the CAE SP of SI08994 or later. ODBC latency was finally fixed in this SP.

2) Adjust prestart and maximum use attributes on QZDASOINIT jobs. I have my system set to prestart 650 QZDASOINIT jobs (used for ODBC's) and end and restart each job after 200 uses.

3) OPTIMIZE YOUR ODBC's. I can't stress that enough. There are case studies available from JDE that discuss pre-fetch, data compression, SQL packages and default libraries, local caching, lazy close support, extending dynamic support, etc. Every system is a bit different and there is a real potential to increase overal performance here.

4) Benchmark your system for a couple of days (preferably busy times on busy days) and watch for overactive CPU, drives averaging more than 25% busy. (big problems after 40% busy), page faults in based pool avaraging greater than 2 faults/second per active jobs. (For instance, if you average 200 consecutively active jobs in your base memory pool, you do not want to page more than 400 faults per second.), more than 10 faults/second in your machine pool.

5) I also found much performance improvement from keeping up with CUM's, Hyper's, and DB updates for AS400/DB2. Also, make sure to keep up with JDE required PTF's and Temporary Storage PTF's. THERE WHERE MANY, MANY FIXES HERE.

6) Consider enabling SMP (Symetric Mutliprocessing)

7) Consider turning on memory manager so memory allocations are automatically adjusted by the OS when needed (Paging option = *CALC)

8)Review memory allocations to your 4 (or more pools). Mine were default and out of whack for what we do. You can adjust these through WRKSHRPOOL

There are more...they just aren't comming to me right now.

I have done all of the above (and upgraded my disk IO card based on a bottleneck found during benchmarking) and my AS400 system went performing like a dog, to offering impressive sub-second response time.

Good Luck.

Ryan Hunt

ES: AS400 V5R2,
Clients: WIN2K FAT, and WIN2K TSE w/ Citrix 1.8,
DS: WIN2K

Hi Tim,

We are having the same problem. What was the eventual resolution?

Regards

Hi ,
I am experiancing the same problem. I have logs that show this time blow out as long as 59 seconds. If any one has any ideas or has fixed this problem in the past your input would be apreciated.

Thanks
Matthew

Leroy & Matthew,

What are your OS/400 levels? Has anything changed on your system between the last time the system operated properly and when you first noticed the problem?