|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.