RE: Performance problems using dataqueues to NT.

Evidently my reply (see below) is causing no end of problems for Debbie
Hatt.

Suffice to say, she would like me to retract thr reply below and replace it
with:

"We are investigating the behavior of the PURGE parameter and will post
again when we have a more definitive description of its behavior".


Frances Stewart
Java II and Applications Enablement
External: (507) 253-2795
Tie-line: 8-553-2795
IBM Rochester

---------------------- Forwarded by Frances Stewart/Rochester/IBM on
10/02/2000 07:31 AM ---------------------------


To:   JAVA400-L@midrange.com
cc:
From: Frances Stewart/Rochester/IBM@IBMUS
Subject:  RE: Performance problems using dataqueues to NT.  (Document link:
      Database 'Frances Stewart', View '($Sent)')

I have spoken with Debbie Hatt on this and looked at the help on the PURGE
option, and here is what I have learned (with some clarification for Java
programmers for whom "classes" has a different meaning than AS400 *CLS
type):

   The "classes" being referred to are *CLS objects on the AS/400, not Java
   classes. An AS/400 *CLS object contains parameters that control the
   running of a routing step for a subsystem which affects all jobs running
   in that subsystem.

   The PURGE parameter on the *CLS object can be *NO or *YES.
   *NO indictes that jobs running in the subsystem (e.g.  for WebSphere
   3.02 this would be QEJBSBS) will not be moved out of main storage and
   put into auxilliary storage at the end of a time slice or when beginning
   a long wait. However when main storage is needed to run other threads in
   the same storage pool, pages belonging to threads in a job in a long
   wait or at the end of a time slice may be moved to auxilliary storage to
   accommodate pages needed for other threads or jobs.

   *YES would be better named *MAYBE. A decision is made by the operating
   system code on whether move a job out of main storage into auxilliary
   storage if it is eligible. This option says that if the operating system
   deems it necessary or wise to move the job, it is OK to do so.

   In V4R5, Program Activation Groups (PAGs) no longer exist, so whether
   PURGE is *NO or *YES does not matter.

   In V4R4, depending on your system, you may want to change the value to
   *NO, but typically this would be decided after having performed a system
   performance analysis over the subsystem pool with a typical workload
   running to determine if such a change is required.

One question I have is what performance improvement percentages have you
seen on WebSphere 3.02 between the two settings (i.e. out of the box versus
changing QEJB/QEJBCLS to have PURGE(*NO)). Running what type of
application? And on what OS/400 release level?


Frances Stewart
Java II and Applications Enablement
External: (507) 253-2795
Tie-line: 8-553-2795
IBM Rochester


mandy.shaw@uk.catalyst-solutions.com@midrange.com on 09/28/2000 10:52:56 PM

Please respond to JAVA400-L@midrange.com

Sent by:  owner-java400-l@midrange.com


To:   JAVA400-L@midrange.com
cc:
Subject:  RE: Performance problems using dataqueues to NT.



A comment - the latest versions of both Domino and WebSphere Application
Server on AS/400 *still* have their classes shipped with PURGE(*YES), which
is quite extraordinary in my view since both products involve very large
numbers of Act->Wait transitions and our experience has shown that it is
essential to switch both, straight away, to using PURGE(*NO). It is
essential to have sufficient main storage for either product, but people
who are deploying them, by and large, know that. I do suspect that there
are a lot of people out there using PURGE(*YES) for things simply because
it's the default.
Mandy





"Richard Jackson" <richardjackson@richardjackson.net> on 28/09/2000
20:31:31

Please respond to JAVA400-L@midrange.com

To:   JAVA400-L@midrange.com
cc:    (bcc: Mandy Shaw/Pacific/UK)
Subject:  RE: Performance problems using dataqueues to NT.




Fred:

On a RISC machine with adequate memory, it is irresponsible to use process
purge on an AS/400.  Between 1996 and 1998, purge(*yes) was the IBM/JDE
guideline for ODBC server jobs (QZDASOINIT).  In December 1998, Debbie Hatt
and Alan Wallet discovered the problem and the guideline changed.  Setting
those jobs to purge(*yes) was a very bad idea but we didn't know it at the
time.  I can speak here because it was my decision, after consultation with
the IBM ODBC database guys, to recommend that it be set that way in 1996.
I
made a mistake.  In 1998 and 1999, I spread the word to change the setting.
It took between 6 and 9 months to get the word out to everyone.

I believe that makes highly questionable any assumption on the part of IBM
developers that customers use purge.  If SLIC retains that anachronism, it
should be purged :)

Contact me offline if you want to discuss this further.  You can call
Debbie
Hatt on an inside line.

Richard Jackson
mailto:richardjackson@richardjackson.net
http://www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325

> |-----Original Message-----
> |From: owner-java400-l@midrange.com
> |[mailto:owner-java400-l@midrange.com]On Behalf Of kulack@us.ibm.com
> |Sent: Thursday, September 28, 2000 8:23 AM
> |To: JAVA400-L@midrange.com
> |Subject: Re: Performance problems using dataqueues to NT.
> |
> |
> |
> |Many waiting primitives in the bowels OS/400 have options coded
> |in them to
> |help overall performance in the system. The optiosn tell SLIC whether a
> |wait is expected to be long > 2 seconds or short < 2 seconds.
> |This has a direct effect on how the scheduler treats the waiter, on
> |priority of the waiter, and on whether the waiter is immediately
> |paged out
> |or what. There's a significant transition that occurs in SLIC at the 2
> |second mark.
> |I suspect is related to this in some fashion.
> |
> |"Do you believe that my being stronger or faster has anything
> | to do with my muscles in this place?" ... "Free your mind."
> |Laurence Fishburne as Morpheus in 'The Matrix'.
> |
> |Fred A. Kulack  -  AS/400e  Java and Java DB2 access, Jdbc, JTA, etc...
> |IBM in Rochester, MN  (Phone: 507.253.5982   T/L 553-5982)
> |mailto:kulack@us.ibm.com   Personal: mailto:kulack@bresnanlink.net
> |AOL Instant Messenger: Home:FKulack  Work:FKulackWrk
> |
> |
> |+---
> || This is the JAVA/400 Mailing List!
> || To submit a new message, send your mail to JAVA400-L@midrange.com.
> || To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
> || To unsubscribe from this list send email to
> |JAVA400-L-UNSUB@midrange.com.
> || Questions should be directed to the list owner: joe@zappie.net
> |+---

+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---



      Regards,
      Mandy Shaw

      Catalyst Solutions plc
      Kingfisher House
      Frimley Business Park
      Camberley
      Surrey
      GU16 5SG
      UK

      http://www.catalyst-solutions.com
      Email: Mandy.Shaw@uk.catalyst-solutions.com

      Telephone: +44 (0)870 166 1000
      DDI: +44 870 166 1324
      Facsimile: +44 870 168 3920
      Mobile: +44 410 447966
      Email to mobile 'phone: mandyshaw@sms.genie.co.uk





----------------------------------------------------------------------
Catalyst Solutions plc.  Registered No 2918101.
Registered @ Kingfisher House, Frimley Business Park, Frimley,
Surrey. GU16 5SG   U.K.

NOTICE:
This message is intended only for the named addressee(s) and may
contain confidential and/or privileged information. If you are not the
named addressee you should not disseminate, copy or take any action
or place any reliance on it. If you have received this message in error
please notify postmaster@catalyst-solutions.com and delete the message
and any attachments accompanying it immediately.
----------------------------------------------------------------------


+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---





+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---