× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Performance problems using dataqueues to NT.
  • From: "Richard Jackson" <richardjackson@xxxxxxxxxxxxxxxxxx>
  • Date: Fri, 29 Sep 2000 08:41:44 -0600
  • Importance: Normal

Ms. Shaw:

Thank you very much for posting that!  Could you post the class
library/name?  Let's try to fix this right now.

IBM has a lot of Domino customers who aren't experts in AS/400 work
management.  Those customers are probably paying a price for a silly
decision to ship classes with a performance-killing setting.  Since this is
a known issue, IBM should be telling everyone - like a HIPER PTF.

Debbie Hatt and Alan Wallet figured out the purge setting at my customer in
Oxford England.  Then Alan Wallet called and told me about it.  I tried it
out at a customer site a few days later and it worked.  I started to tell
everyone who would listen and a lot of people who didn't want to hear.
Purge(*yes) causes a great deal of unnecessary synchronous writes to disk
drives - both database and non-database.  That is the symptom.  You can see
it in the Performance Tools system report and component report or extract
the information from the performance files.

For general consumption - not directed at Ms. Shaw:

People make mistakes.  I have made my share and I will make more.  It is the
price for being near, at, or beyond the bleeding edge.

When we try to cover up mistakes, it takes longer to move forward.  If we
hammer people when they make mistakes, then they are less likely to
experiment in the first place and bad advice and previous mistakes are
concealed and propagated.  If senior people are hammered for errors, junior
people won't take chances.  Covering up errors slows invention and progress.

I read a news group where one of the people who posts use a tag line that
goes something like this: "If we knew what we were doing, they wouldn't call
it research"  Albert Einstein.  I don't think that Dr. Einstein said that
but it is true.

If we fix mistakes when we see them, then move forward, that is the best
that we can do.  People are NOT either perfect or incompetent without a
middle ground.  More mistakes (or "errors" or pick your euphemism) are made
near the bleeding edge.  If you want to get close, learn to enjoy the
education.

If you think that too many mistakes are being made on a project, check
around.  It might turn out that you are on the bleeding edge and no one told
you.  It might turn out that you were told that something was a mature
tested technology but you might discover that no one is using it in
production yet.  In case it isn't obvious, a thing that isn't in production
anywhere is not mature.  There is a lot of that going around.


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
> |mandy.shaw@uk.catalyst-solutions.com
> |Sent: Thursday, September 28, 2000 9:53 PM
> |To: JAVA400-L@midrange.com
> |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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.