AW: QPFRADJ/BPCS - more info -- MIDRANGE-L

Clare,

sure - I just wanted to point out one possible performance problem.

Regards,

Oliver


> -----Urspr�ngliche Nachricht-----
> Von:  Clare Holtham [SMTP:Clare.Holtham@btinternet.com]
> Gesendet am:  Samstag, 28. Juli 2001 09:50
> An:   MIDRANGE-L@midrange.com
> Betreff:      Re: QPFRADJ/BPCS - more info
> 
> Oliver,
> There can be serious memory problems without paging/faulting showing up on
> the WRKSYSSTS screen in the more recent OS versions/CPUs. An unofficial
> quideline a while ago was 1Gb per CPU or 1.5 for later CPUs. And it is
> crucial for SQL, which makes decisions based on amount of memory
> available.
> Clare
> 
> ----- Original Message -----
> From: <oliver.wenzel@cibavision.novartis.com>
> To: <MIDRANGE-L@midrange.com>
> Sent: Thursday, July 26, 2001 11:06 AM
> Subject: AW: QPFRADJ/BPCS - more info
> 
> 
> Hello,
> 
> on the wrksyssts screen, press F21 and option 3. Then watch the paging
> data.
> If there is a lot of activity in the three
> right-most columns, you have serious performance problems.
> 
> More info about these paging data can be found in the work management
> guide.
> 
> 
> Regards,
> 
> Oliver
> 
> > -----Urspr�ngliche Nachricht-----
> > Von: Samantha L Smith [SMTP:ssmith79@csc.com]
> > Gesendet am: Donnerstag, 26. Juli 2001 10:19
> > An: MIDRANGE-L@midrange.com
> > Betreff: QPFRADJ/BPCS - more info
> >
> >
> > Thanks alot for the responses -
> >  - I was a little scared to reply and couldn't type too well as my
> > knuckles
> > are sore from the wrapping they got for leaving the subject blank.....
> but
> > I will not make that mistake again.....ever....:)~
> > Anyway:
> > Originally our boxes were configured by external consultants and they
> > based
> > the set up on some BPCS perfromance recommendations,  where appropriate,
> > and the decision was made not to enable QPFRADJ.
> > However, now the system has grown, and batch is at an all time slow, and
> > in
> > a desperate bid to speed things up without spending any money, I'm
> > exploring the obvious.
> > We have job currently which shifts the memory around for day/evening
> > activities, but I didn't think it was as efficient as QPFRADJ, and
> wanted
> > to try it, but before I can CHANGE anything, we must raise change
> request,
> > which requires justifiaction, research and info, which u have provided.
> > I just wanted to be sure that no one had any horror stories of changing
> > the
> > val and batch taking 10 hours instead of 5....
> > We have alot of SBS as you can see and most jobs do not route into the
> > base
> > pool, and I may change those that do, if I don't get good results from
> > pfradj.
> > WRKSBS
> > Opt  Subsystem   Storage (K)   1   2   3
> >      BATCHCATSP           0    2   6
> >      BATCHDEV         10000   10
> >      BATCHIT              0    2   6
> >      BATCHPG              0    2   6
> >      BATCHSP              0    2   6
> >      BATCHUK              0    2   6
> >      BPCSCS               0    2   4
> >      EDISBS           30000    2  11
> >      HERMIT               0    2   4
> >      INTERDEV         20000    7
> >     INTERIT              0    2   5
> >  INTERPG              0    2   5
> >  INTERSP              0    2   5
> >  INTERUK              0    2   5
> >  ORDERPOST            0    2   4
> >  QBATCH               0    2   6
> >  QCMN                 0    2   4
> >  QCTL                 0    2
> >  QINTER               0    2   5
> >  QPGMR                0    2   6
> > QSERVER              0    2   4
> > QSNADS               0    2   4
> > QSPL                 0    2   3
> > QSYSWRK              0    2
> > Q1PGSCH              0    2   2
> > RBTSLEEPER           0    2
> > ROBOTCTL             0    2   6
> > SQLMONITOR       40000    9
> > SYSCHECKER           0    2
> > TRAX             16000    2   8
> >
> > WRKSYSSTS:
> >
> >   1     555000    170636  +++++  *MACHINE
> > *FIXED
> >   2     384016         0     50  *BASE
> *CALC
> >   3     300000         0      2  *SPOOL
> *CALC
> >   4      15000         0     11  *SHRPOOL2
> *CALC
> >   5    2000000         0     35  *INTERACT
> *CALC
> >   6     300000         0      6  *SHRPOOL1
> *CALC
> >   7      20000         0     13   1          INTERDEV    QGPL
> > *FIXED
> >   8      16000         0     15   2          TRAX        QGPL
> > *FIXED
> >   9      40000         0      4   1          SQLMONITOR  QGPL
> > *FIXED
> >  10      10000         0      4   1          BATCHDEV    QGPL
> > *FIXED
> >  11      30000         0      6   2          EDISBS      EDIV32F
> > *FIXED
> >
> > Too much info....or not enough?
> > Any more input would be excellent.
> >
> > Many thanks
> >
> > Sam
> >
> >
> >
> >
> > thomas@inorbit.com@midrange.com on 26/07/2001 04:40:38
> >
> > Please respond to MIDRANGE-L@midrange.com
> >
> > Sent by:  owner-midrange-l@midrange.com
> >
> >
> > To:   MIDRANGE-L@midrange.com
> > cc:
> > Subject:  Re: [QPFRADJ/BPCS]
> >
> >
> > Samantha:
> >
> > <disclaimer>
> > Everything in here is pure personal opinion from personal experience. I
> > have no education background in this area other years of reading
> manuals,
> > articles and just plain trying stuff. IBM might have far better answers.
> > </disclaimer>
> >
> > No way to know if it'll help in **YOUR** system. If you look through
> your
> > subsystems and find that you have any tasks running in *BASE (possibly
> > with
> > the exception of the subsystem monitors) rather than in private or
> shared
> > pools or if you really have no memory to shift anyway or many other
> > possible factors, then it might not help at all. I suppose in the worst
> > cases, it could even make things worse.
> >
> > It often seems to me that IBM tends to ship configurations that are not
> > well suited for good performance. Just check how many of their default
> > entries point to *BASE, e.g., routing entries to support TCP/IP. And
> since
> > they get income from selling memory, that makes sense. To be fair,
> though,
> > they cannot have a good idea of what **YOUR** system needs at the time
> of
> > delivery.
> >
> > But people are commonly unwilling to change those entries to point to
> > another pool. Further, new custom entries often follow those default
> > examples. So, the memory in *BASE is constantly in use, so performance
> > adjuster has no clean way to shift memory around directly and QPFRADJ
> has
> > minimal effect.
> >
> > Quite a while back, I put together a memory pool configuration utility
> > that
> > I've used with what seems to be decent success. It changes most *sbsds'
> > pool settings, changes any routing entries, changes prestart job
> entries,
> > etc., to settings that have worked for me. I run it on any new AS/400
> I'm
> > responsible for and QPFRADJ=3 has seemed to give noticable improvement.
> >
> > From this, I've believed QPFRADJ has significant value when it's used on
> > appropriately configured systems. (And it might work much better if I
> knew
> > for certain what "appropriately configured" really was.)
> >
> > But, will QPFRADJ=3 work well for you? Maybe. Post your subsystem
> > descriptions, routing entries, pool definitions, etc., and let's see.
> > (Toungue-in-cheek comment but based on at least some unfortunate
> reality.)
> > At the worst, you can always set the value back.
> >
> > Tom Liotta
> >
> > On Wed, 25 July 2001, "Samantha L Smith" wrote:
> >
> > > Really want to know if anyone has had any issues using QPFRADJ, set to
> > 3,
> > > with an ERP like BPCS, had conflicting recommendations.
> >
> >
> > --
> > Tom Liotta
> > The PowerTech Group, Inc.
> > 19426 68th Avenue South
> > Kent, WA 98032
> > Phone  253-872-7788
> > Fax  253-872-7904
> > http://www.400Security.com
> >
> >
> > ___________________________________________________
> > The ALL NEW CS2000 from CompuServe
> >  Better!  Faster! More Powerful!
> >  250 FREE hours! Sign-on Now!
> >  http://www.compuserve.com/trycsrv/cs2000/webmail/
> >
> >
> >
> >
> > +---
> > | This is the Midrange System Mailing List!
> > | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to
> > MIDRANGE-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator:
> > david@midrange.com
> > +---
> >
> >
> >
> > +---
> > | This is the Midrange System Mailing List!
> > | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to
> > MIDRANGE-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator:
> > david@midrange.com
> > +---
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
> 
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---