RE: V2R3 CISC to V4R2 RISC - Do we dare? -- MIDRANGE-L

Something that I think PM/400 SHOULD handle during a release upgrade is
to kick off a job that does:
CVTPFRDTA FROMLIB(QMPGDATA) TOLIB(QMPGDATA)  

You STILL need to do that manually for performance data that is kept
from before a release upgrade.

I still continue to find minor niggling problems with PM/400 after
release upgrades.  My latest (V4R1 to V4R2) went in and changed the
schedule times for my Q1PCM1 job (upload data to Rochester) job, and
removed the PMOFF/PMON before/after programs (from the PMLINMON command
setup), so of course when it went to dial out to upload to Rochester the
lines was unavailable.



Neil Palmer                                AS/400~~~~~      
NxTrend Technology - Canada   ____________          ___  ~     
Thornhill, Ontario,  Canada   |OOOOOOOOOO| ________  o|__||=   
Phone: (905) 731-9000  x238   |__________|_|______|_|______)   
Cell.: (416) 565-1682  x238    oo      oo   oo  oo   OOOo=o\   
Fax:   (905) 731-9202       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
mailto:NPalmer@NxTrend.com    AS/400  The Ultimate Business Server      
http://www.NxTrend.com

> -----Original Message-----
> From: Rob Berendt [SMTP:rob@dekko.com]
> Sent: Thursday, July 30, 1998 5:47 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      RE: V2R3 CISC to V4R2 RISC - Do we dare?
> 
> You definetly hit one one of the things, the number of days.  Somehow
> ours got set to 999.  But in only went back to 5/29/98, when we
> upgraded OS.  However the IBM'er also was saying that if you jump
> operating system releases that sometimes it won't delete any data, new
> release or old release, until you remove some of the data that was
> prior to the new release that you are running.  Something about
> different data formats.  We had to step through some hoops to delete
> that data.
> 
> 
> 
> 
> npalmer@NxTrend.com on 07/30/98 04:41:20 PM
> Please respond to MIDRANGE-L@midrange.com@Internet
> To:   MIDRANGE-L@midrange.com@Internet
> cc:    
> Subject:      RE: V2R3 CISC to V4R2 RISC - Do we dare?
> 
> Re PM/400 - QMPGDATA library
> 
> 4GB !!!
> 
> Sounds like someone has the parameters for PM/400 set to some
> ridiculously high value for days to keep performance data.
> 
>                         Work with PM/400 Customization            
>                                                                   
> Type changes, press Enter.                                 System:
>                                                                   
>       High priority limit  . . . . . . . . .   20                 
>                                                                   
>                                                S M T W T F S      
>       Trending days  . . . . . . . . . . . .     Y Y Y Y Y        
>                                                                   
>       First shift  . . . . . . . . . . . . .    8:00    - 18:00   
>       Second shift . . . . . . . . . . . . .   18:00    -  8:00   
>                                                                   
>       Performance data library . . . . . . .   QMPGDATA           
>                                                                   
>       Performance data purge days  . . . . .    10                
> 
> 
> GO QMPGLIB/PM400  option 6
> 
> Reduce Performance Data Purge Days to something reasonable.
> PM/400 itself can live with one day, as it purges the data every night
> at midnight.
> The only reason to keep the data longer is if you want to run
> Performance Tool reports or Performance Modelling using the full
> unfiltered data in QMPGDATA.  I occasionally run performance tool
> reports a week after the data was gathered, so set it for 10 days.
> Either you have a high number of days, or a VERY busy machine with a
> ton
> of performance data.  Either way, reduce the number of days.
> 
> 
> 
> Neil Palmer                                AS/400~~~~~      
> NxTrend Technology - Canada   ____________          ___  ~     
> Thornhill, Ontario,  Canada   |OOOOOOOOOO| ________  o|__||=   
> Phone: (905) 731-9000  x238   |__________|_|______|_|______)   
> Cell.: (416) 565-1682  x238    oo      oo   oo  oo   OOOo=o\   
> Fax:   (905) 731-9202       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
> mailto:NPalmer@NxTrend.com    AS/400  The Ultimate Business Server
> 
> http://www.NxTrend.com
> 
> > -----Original Message-----
> > From:       Rob Berendt [SMTP:rob@dekko.com]
> > Sent:       Thursday, July 30, 1998 2:07 PM
> > To: MIDRANGE-L@midrange.com
> > Subject:    Re: V2R3 CISC to V4R2 RISC - Do we dare?
> > 
> > That list of files was from last Thursday.  We ran that RCLSTG
> > SELECT(*DBXREF) on Friday.  Now that biggest file is down from
> > 1,674,665,984 to 1,286,799,360.  Gee, 400 meg.  You suppose some of
> > those people who are totally opposed to running a RCLSTG might
> > comtemplate it now?  At $0.60/mb that is $5,840 worth of disk space.
> > 
> > The SSA user profile was in there to say "It's huge because we have
> so
> > many BPCS objects.  We have so many BPCS objects that is also why
> the
> > database cross reference file is huge."  This is not a problem with
> > BPCS.  This is just our development machine support a dozen or more
> > 400's running BPCS in multiple versions and custom mods.  Therefore
> we
> > keep full copies of the programs and data on this machine for
> testing.
> > 
> > I didn't show you our biggest file.
> > Library     Object      Object           Object   Text description
> > 
> >                         Type             Size
> > 
> > QMPGDATA    QAPMJOBS    *FILE     4,144,820,224   Job related
> > performance data
> > 
> 
+---
| 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
+---