RE: Database Cross Reference FIles (was: V2R3 CISC to V4R2 RISC - Do we dare?)

Personally, I would like to see a system value you can change if you
DON'T want the damn database cross reference files on your system.  (ie.
if you DON'T use SQL, ODBC, etc. etc).



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 10:16 AM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: V2R3 CISC to V4R2 RISC - Do we dare?
> 
> We haven't done the V2R3 to V4R2.  We've done V3R2 to V4R2.  Follow
> the steps of the 'Roadmap for changing to Power PC technology' very
> carefully.  Since we've done many CISC-to-RISC upgrades we have our
> own instructions written down that go along with the book.  Our
> instructions are tailored for the individual machine, and the upgrade
> path chosen.  For example:  side-by-side, unload/reload, etc.
> 
> I don't know if the tools that estimate disk space include the huge
> files IBM builds once you move from V2R3 up.  For example.  One of our
> AS/400's has many, many objects.  When we upgraded CISC-to-CISC from
> V2R3 to V3R2 we lost about a gig of space.  Yes that was one gig.
> This space could be traced to a half dozen objects that IBM created
> for database cross reference.  It seems that IBM's, and other
> developers, didn't like having to use API's or things like the command
> DSPFFD to find out what fields were in files.  So IBM stores all of
> this in files now and they can just access those.  If you've a dozen
> or so sets of BPCS on your system it doesn't take long to make these
> files huge.  And boy is it fun when they get corrupted.  Hence the new
> parameter for RCLSTG  SELECT(*DBXREF).  One the S20-2163 that takes
> one hour, versus 14 hours for RCLSTG SELECT(*ALL).  At one time I
> heard that if you delete them it just rebuilds them.  I'm afraid that,
> as operating system releases have!
>  gone by, that the dependence has grown on these files and I would be
> loathe to delete them.
> 
> Check this out:
>  Library     Object      Object           Object   Text description
> 
>                          Type             Size
> 
>  QSYS        QADBIFLD    *FILE     1,674,665,984   Cross reference
> physical file 
>  QSYS        QADBIATR    *FILE       190,861,312   Cross reference
> logical file  
>  QSYS        QADBILFI    *FILE       171,986,944   Cross reference
> logical file  
>  QSYS        QADBILLB    *FILE       110,145,536   Cross reference
> logical file  
>  QSYS        QADBXREF    *FILE        48,410,624   Cross reference
> physical file 
>  QSYS        QADBKFLD    *FILE        47,239,168   Cross reference
> physical file 
>  QSYS        SSA         *USRPRF      45,129,728   Group profile for
> BPCS        
>  QSYS        QADBFDEP    *FILE        16,830,464   Cross reference
> dependency fi 
> 
> Whenever you use the SQL command CREATE COLLECTION to build a library
> it will build logical files over these physicals and store them in the
> new library you created.
> 
+---
| 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
+---