RE: Data migration

Ali Macintyre
Thanks, thats great info from a genius! I real appreciate.
Jet

-----Original Message-----
From: bpcs-l-bounces+ronald=techdata.com.au@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+ronald=techdata.com.au@xxxxxxxxxxxx]On Behalf Of
Alister Wm Macintyre
Sent: Sunday, February 13, 2005 1:46 PM
To: SSA's BPCS ERP System
Subject: RE: [BPCS-L] Data migration


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


--
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.

Delivered-To: ronald@xxxxxxxxxxxxxxx