For what its worth, we tried to use the migration tools to get to 405 cd in
the first place, from S/36 BPCS running on M/36 and ran into a heck of a lot
of problems. In the end we used OTHER tools provided by alternative
software houses. This was over 10 years ago, so reality could be quite
different today.

Basically migration is your current file structure logic reality to work
with a later version of the software. It does not let you restructure how
you use BPCS based on what your company has collectively learned since prior
migrations.

At that time in history, we had been operating with like different
environments for each facility, because S/36 BPCS did not support
facilities, and now we wanted to combine them in one environment, adjusting
some controls so first digit of dept work-center etc. meant which facility.
The migration tools would not do that.
We had some modifications. Forget them also.
Management decided to do some changes like restructure the GL accounts.
Migration tools not support that.

With respect to Uncle Milt remarks regarding archives, some versions of BPCS
are superior to others when it comes to saying we don't want certain records
any more, and 405cd was vastly superior to S/36 in that regard, but it still
had lots of such problems. We used the migration to drop all records coded
for deletion (SYS120 does not get all files).

You know how BPCS has some bugs? Migration Tools also.
Pressure to resolve bugs, was much less on the tools than the ERP, for SSA.
So could not pour our data into tools and run whole thing, had to stop at
many steps to fix stuff associated with the bugs at those stages.

I suspected, but never could prove, that the Migration Tools were written
for security 30. Another of my suspicions was consultants doing things in
BPCS while they were signed on as a master security officer.

We were operating on a theory that certain steps would be completed before
certain other steps, and that the disk space estimating resources were
accurate. This failed. On several occasions we ran out of disk space ...
some conversion jobs bombed because disk space consumption reached 100% in
reality, over 100% on AS/400 diagnostics because M36 math not quite right.

When that happens, a reasonable person might presume that what gets damaged
are the files being created at the instant DASD hits 100%, right? No, don't
count on that. You never want to get to that point period.

It is only fair to reveal that we had more than BPCS on our AS/400, so the
DASD estimates might have been messed up by our other applications.

We had other migration complications unrelated to the migration tools.
Mainly in the area of our modifications, where our company incapable of
operating purely with vanilla BPCS.

-
Al Mac
-----Original Message-----
From: bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx] On Behalf Of Don
Cavaiani
Sent: Tuesday, November 30, 2010 4:27 PM
To: bpcs-l@xxxxxxxxxxxx
Subject: [BPCS-L] 405cd to erp/lx migration

Anyone do this on their own?

Are the migration tools included with the upgrade - and if not, what
would be strictly the cost of the tools - with no training or support
added in? Is it true that the migration software runs on the IBM i? Is
there much more to it (to moving over existing data) than cpyf with
*map?



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 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.