|
Thank you for your reply. Yes I agree that the steps I outlined are not 100% accurate, BUT they do provide a very quick & simple method of finding out an approximate count. To do an actual analysis using format names and other criteria to chase ITEMMAST1 & 2 satellite files would be quite involved. The steps I outlined take maybe 2 or 3 minutes, and I STILL received NO specific replies with data. Why did I receive no responses with data? Was it asking for company info that is not to be shared? ----- Original Message ----- From: "Walden H. Leverich" <WaldenL@xxxxxxxxxxxxxxx> To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx> Sent: Thursday, February 10, 2005 9:09 AM Subject: RE: how many item master files is too many? > >You'd be better off using the select count(*) as num_part from itemmast > > Don't know about that. That would tell you how large your item master is > -- or more accurately, how many items you have in the master. I think > Joel is looking for how many instances of the item master you have on > the system. For example, 1 in production, 1 in training, 1 in QA, and 3 > in developer libraries. > > However, I'm not sure I like the query he's running to find that out > (sorry Joel). While he's not looking directly at the record format level > id, he is looking at two of the key components of it, the number of > fields and the record length, and he's only looking for files w/the same > name, number of fields and length, and only physicals. > > I'd be less concerned about a system that had 10 copies of ITEMMAST that > were all the same than a system that had 4 copies all with different > record lengths and one of which was a logical. > > The more mature a development process is the more likely you'll have > multiple copies of a file, to support development & unit testing, > integration testing, QA testing, training, and production, for example. > However, if you have multiple files with the same name but different > record lengths I'd be really worried. > > Oh, and if you're looking for complexity, don't forget to ask how many > files make up the "item master" file. I've seen situations that had: > ITEMMAST - the original file > ITEMMAST1 - new fields that are needed to describe an > item, but they didn't want to change ITEMMAST > ITEMMAST2 - more new fields, came about 2 years after ITEMMAST1, > again, didn't want to change ITEMMAST or ITEMMAST1. > > An "item" is made up of fields from all three files. Now we're getting > complex. > > -Walden > > ------------ > Walden H Leverich III > President & CEO > Tech Software > (516) 627-3800 x11 > WaldenL@xxxxxxxxxxxxxxx > http://www.TechSoftInc.com > > Quiquid latine dictum sit altum viditur. > (Whatever is said in Latin seems profound.) > > > > -----Original Message----- > From: midrange-l-bounces@xxxxxxxxxxxx > [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steve Dodkins > Sent: Thursday, 10 February, 2005 03:47 > To: 'Midrange Systems Technical Discussion' > Subject: RE: how many item master files is too many? > > You'd be better off using the select count(*) as num_part from itemmast > > > > > -----Original Message----- > From: Stone, Joel [mailto:StoneJ@xxxxxxxxxxxxxxxx] > Sent: 09 February 2005 18:25 > To: Midrange Systems Technical Discussion > Subject: how many item master files is too many? > > > I would like to find out if my company's database is a bit too complex > (as > I'm sure many are). > > One simple test I thought of comparing is: How many physical files of > one > type are a company's server. > > For a simple sampling of other companies, I would like to know how many > item > master (product) files your company has on its AS/400. > > If you would be able to provide this info (I will keep this anonomous of > course), I would be grateful. > > Please do the following steps if you could: > > 1) Identify the name of your item master file (to yourself), lets > call > it ITEMMAST > > 2) Find out the number of fields in the file ITEMMAST, call it > #fields > > 3) Find out the record length of ITEMMAST, call it reclen > > 4) Run the following SQL statement > > runsql 'select * from qsys/qadbxref where dbxnfl=<#fields> and > dbxrdl=<reclen> and dbxatr=''PF''' > > > 5) jump to the bottom of the list > > 6) make sure that the files appear to be actual item-master type > files > > 6) Email the number of records to me. > > > Thank you so much for your assistance! > -- > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing > list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. > -- > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing > list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. > > > -- > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.