Re: Data mapping -- BPCS-L

In the absence of the kinds of resources I referred to earlier, you might be interested in some of the kinds of tools I am able to use at GWT.

1. I do have some excellent resource material supplied by the various firms we have done business with over the years for BPCS Education, BPCS tech support, and conversion projects, and I also subscribe to BPCS newsletters published by outfits we not yet doing business with. I push this stuff out to the end users, and sometimes it goes missing. 2. We have a version of BPCS that came with source code. This has mixed blessings since we do not have AS/Set. In theory, we can back trace field definitions, but I have found this to be very cumbersome. 3. I have generated *OUTFILEs to a collection which I access via Query/400 to generate reports of value to both myself and in some cases to end users. 4. I use Query/400 quite heavily 5. Some BPCS data in vanilla form is cumbersome to access or reference ... I have created our own reference listings & inquiries against the data ... for example, key in an item or customer and get a picture of the special pricing on it ... list some files, such as reason codes and item classes, by the text description of those codes ... try to identify where coding is misleading, and create reference lists of what the underlying reality is ... on BPCS_L there was recent reference to some of this, such as Customer TERMS

Examples from above

GO CMDREF accesses a command whose output can be sent to an *OUTFILE Put that command with a CL that adds to the *OUTFILE based on several libraries and we have an index of what BPCS programs access what other objects Due to soft coding it is not 100% complete, but usually a big help to me when running a query to identify ... what are all the programs that mess with this file or any of its logicals, or how back trace does this report get called.

Use DSPFFD to get a printed layout of the fields of a file. Get at compiled source code of program accessing that file, that puts the field list into nice format of field names definitions text description, or create a dummy program that does nothing with the file just to get access to this

Use RUNQRY *N file name then F4
for example RUNQRY *N IIM
Change the bottom line of the F4 to *Yes

I have placed all this in an CL so that from a menu option we can get at what file, library, member, we want to run it against

This lets us dump contents of any BPCS file without having any query definition setup

I can do some selection criteria, view contents of file, then F12 and change selection criteria I jot down notes on the earlier DSPFFD or external source list

Which fields are totally unpopulated. Which fields seem to be 100% populated with the exact same value Which fields contain data that appears to be mislabeled ... for example, this or that looks to me like customer #, facility, but is not labeled as such, nor is it using consistent BPCS back referencing Which fields are used for an obvious purpose, in which it is equally obvious that we have some bad data in here, of what nature. For example, this is a date field in which some of the dates lack century, so we have another program to trace without Y2K fix.

I can dump the file layout to a PDM SEU source document, then annotate it with my research notes.

It has been a while since I had time to mess with it, but I have a string of data error mapping programs: * Use *OUTFILE to get directory of BPCS files * That *OUTFILE is now input to a program that will analyze each file in turn, for the kinds of problems we have seen in the past, to see if any of those problems have reared their ugly heads again, or if past problems that seemed not worth the trouble to mess with, have grown in size. * What is the oldest date of stuff in the file ... how many days months years is that ... bold print the sucker if it is more than 3 years old. * If this is a detail file, match it against its relevant master files and get a count of how many records are in there that ought to have a customer master, vendor master, item master, etc. but don't. * Lots more

The last time I messed with this, I realized that as I was adding more stuff worth checking, the program was approaching the practical ceiling of how large a program can be, in terms of lines of code, so my next plan was to split it into 4 programs: check accounting file problems, check problems with "rules" files (that control how BPCS functions such as the "engineering" files); check work in process (orders, inventory) problems; check all other files problems.

My theory behind this is to get an inventory of our bad or dirty data, and make significant progress cleaning it up, and intercepting its creation, instead of the normal process of having vast quantities of the stuff in which users at random collide with pieces of it, then we investigate the details of that collision, and end up with a band aid on a problem that we do not have a good big picture on.

Although I have made significant progress on this over the years, it is what I work on when I run out of more important stuff to work on, which is very seldom.

- Al Macintyre http://www.ryze.com/go/Al9Mac Find BPCS Documentation Suppliers http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/ Part time may get commission from some BPCS vendors for helping them ... I will now say in a post if the product I commenting on is also one potentially involved with this ... not that I have made anything from this yet.