RE: [BPCS-L] Data migration

[Alister Wm Macintyre <macwheel99@xxxxxxxxxxx>]

I try to avoid getting into things that either are very dangerous, or the 
odds of success very low.
But if I was required to tackle this, here is how I would go about it.

1. Remind co-workers of the degree to which BPCS files intricately 
intertwined so this behavior is not for people not intimately familiar with 
the whole infrastructure.
2. Suggest management have tech support review my plan of action to catch 
any nuances I missed.
3. Go for it.

Data files in the PC world are rather alien compared to in the 400 world.
variable vs. fixed field and file lengths
ASCII vs. EBCIDIC
translating all that has been made possible by native stuff with the 400, 
but it can be a bit geeky to operate, so there is a vast universe of 
shareware to make the process go more smoothly.

The difficulty is not in the translation of the data, but in integrating it 
with BPCS or whatever is your 400 application.

There can be risk that the data from a different platform does not adhere 
to the rules of 400 data.
Do you know what a decimal data error is?

However, when using 400 tools to copy data from one file to another, you 
can let the 400 catch the errors for you, then you abort the copy, knowing 
where there is bad data, work on fixing it, then try again, until you can 
go all the way, with data now known to be clean.  If you take option to 
ignore errors, then you are asking for trouble down the road when you got 
invalid data interjected into your files.

The 400 comes with a bunch of capabilities ... in Client Access you can 
specify name of file to upload or download to where ... for safety it is 
best to identify some target other than the ultimate destination, because 
you not want to mess up your 400 software packages with data not in sync 
with external file rules.

Now once you have some data uploaded such as cut & paste from Internet, or 
Client Access, or some shareware package to make the process simple, there 
are some IBM 400 copy functions where you can copy from one 400 object to 
another ... ideally the field names should be same in both copies ... so 
suppose you have a file in BPCS and you have access to the source code, you 
can create another file in another library that has the same names of the 
fields as the BPCS file.

So now this look-alike file in the other library is populated by stuff that 
came from outside of BPCS, and perhaps the file might have some fields that 
are not up to snuff with respect to clean content, so you need some program 
to validate and fix content, clean up what you got, then use the IBM copy 
function to add those records to the real BPCS file.

Now in all probability there is now stuff in the file you added to that the 
other BPCS files do not know about, so now run some of the reorg functions 
on menu SYS / 23 to get the OTHER BPCS files in sync with the one you just 
messed with.

Better go thru the whole process in the test environment a few times to 
make sure you caught all the nuances.

Now all that is when the data can go into a single BPCS file   When there 
are multiple BPCS files to be populated, using rules like one header 
matching several details and various control fields being some default if 
not already valid content in various control files, you really need some 
400 software to organize which population is to go where, using some 3rd 
party package best suited to that function ... I love FILE TRACK for that 
purpose.  It can also do the bad data cleanup for you.

If you plan to do this on a regular basis, then perhaps you ought to get a 
software package that helps the whole process go more smoothly, such as 
FOXTROT in which you get a script of what the end user might do at a BPCS 
inquiry screen, and where that person gets the data in the PC Internet 
world, and it emulates the human cut and paste from elsewhere into BPCS, 
with ability to edit the script, so when you all done, a massive file of 
stuff outside of the 400 has been integrated into BPCS, without modifying 
BPCS software or file structure, and everything is in sync, and several 
clerical jobs have been eliminated, perhaps including yours.
:
> Hi Al Macintyre
> Thanks for the information, but you never really specified how you do it
> yourself. I know its extremely dangerous. How do you do it?
>
> Kind Regards
> Jet
>
> -----Original Message-----
> From: Alister Wm Macintyre
>
> Warning ... this can be VERY DANGEROUS if you not know EXACTLY what you
> doing ... not with the data transfer between PC and 400, but with the BPCS
> files.  The data structure assumes that many files will be in
> synchronization with each other and with the external file layout.  If you
> tamper with that, without going through the regular program structure, you
> can cause all of BPCS to crash.
>
> We do BPCS data to XL all the time, but I consider the reverse direction to
> be so suicidal that I keep it a secret from most of my co-workers.
> :
> >Is it possible to import data from excell/access via BPCS (Ver 6.0) Windows
> >client?
> >If so how do you go about it?
> >Regards
> >Jet
>
> -
> Al Macintyre  http://www.ryze.com/go/Al9Mac