Re: BPCS S/36 to BPCS/400 conversion can be a nightmare -- BPCS-L

     {Ata510@aol.com]
> Usually the problem is converting modifications or modified files - that is 
>  indeed outside the scope of Helpline.

          [Al Macintyre]
When we converted from BPCS/36 to BPCS 405 CD we decided to throw out all our 
modifications & just move the core data.  None of our mods changed file 
lengths, they were exclusively adding new fields to the filler areas of BPCS 
files.  Thus our modifications should not have been a factor in the SSA 
conversion tools giving us fits of frustration.

Our major problems, from a time wasting perspective, included:

SSA sending us tapes that would not load - defective tapes, wrong kind, CISC 
without observables so our RISC system could not process the data.  We went 
around the loop several times, making sure they understood what was needed on 
the tapes to be sent & them sending us wrong tapes again.  This was not a 
problem with my know-how.  We had IBMers helping us try to load the tapes & 
our consultants got us a technical expert who spent an entire day trying to 
load tapes & use their contents, without success.  I showed him the tapes I 
had & related the problems, and he verified that it was not a problem with my 
know-how, we did in fact have 4 sets of SSA tapes that were no damn good.

However, there were times with BMRs when I gave up trying to load after about 
3 retries, and the consultants had a go with them & about 1/2 the time they 
agreed that the tapes were bad & 1/2 the time they managed to extract the 
data, so any time I had a failure to load the data, there was that 
uncertainty whether it was me or the tapes.  Very rarely did BMR tapes 
content agree with the BMR documentation of how the data was orgainzed, so 
there was a chunk of time with display tape & dump tape trying to figure out 
how it was on the tape - SSA used several different methods with no apparent 
consistency.

SSA sending us license keys that failed.  Usually we would get a key about a 
week before we needed to use it, then discover at a crucial step that it was 
no good.  Thankfully when we called SSA on these crises we did not get the 
usual Help Line runaround & they got back to us with a new key within a 
matter of hours, so a weekend conversion series of steps was not blown.

Software keys are a concept new to AS/400 - we did not have this on BPCS/36 & 
in fact we did not have it with IBM on our 400 until V4R3 - so although we 
saw reference in the documentation to software keys, and on tapes to the fact 
that we might need one, we had no idea what this meant & this was only one of 
many things we had no idea what meant.  SSA documentation assumed that 
everyone knows what software keys are, and what are prudent procedures.  This 
is not a valid assumption for people who are converting from systems that 
never needed them.

Thus the first failure needing one -> research that our account was not 
financially up-to-date --- we had paid like 90% of it, with the missing 10% 
for some add-ons that we discovered during the conversion that we would need 
& why had we not paid for them, well accounting swears up & down that they 
never got the invoices from SSA.  This was solved with a temporary key (which 
did not work) & SSA financial faxing particulars to our accounting dept.  

Lesson from this - you need to do SSA financial job for them.  Have you been 
billed for everything you got, and what is the status of paying for it?  If 
not, seek clarification promptly, so it won't cause a problem when you need 
software keys.

Nailing down the correct set of instructions to use - there was great overlap 
in sets of instructions covering portions of the same things - so the correct 
path was jump back & forth these instructions those others third set then 
back to first set.  Different sections of course.  Some chunks of 
instructions had been re-written, and replaced in another document, so that 
portions of some documents were obsolete, but still contained sections we 
needed to use.

Thankfully our consultants had some add-ons to help us navigate the maze of 
SSA documentation.

I was new to OS/400, so when I made a typo transcribing long strings of CL, 
it was not apparent to me what the heck the command should look like, and 
there were typos in the instructions also.

It was quite obvious that we did not have the technical know-how to be 
efficient with this, but it was not obvious what know-how was optimal to 
learn in what sequence.  I was sent off to various IBM classes to learn stuff 
in which after I got to the classes it was obvious to me that I lacked 
pre-requisites for a lot of the info to sink in.

I think there needs to be something like the SSA sizing questionnairre which 
tests the technical know-how of the would be conversion staff, from which a 
road map of education is dictated.

It did take me several tries to figure out how to get the data off of S/36 in 
the right format for the 2.0 conversion to accept it.

Our consultants had no patience to figure out security problems - any time 
anyone was refused admission to anything, they just made everyone a security 
officer.

There's a multitude of stages that the data transitions through - at many 
stages there are menu options that need to be taken in which the job might 
run in 5 minutes or 5 hours to get to the next human intervention.  When it 
got to a stopping point, where we could sign off, take a break, we would 
randomly check files to see if they were populated, because we were finding 
that some files that were fully populated at one stage were empty at a later 
stage & it took a while to figure out at what point that was happening.  

Since there were so many menu option intermediate stages it became binary 
search - let's check the most suspect files after every 3-5 menu options.  We 
found the points & wrote fix programs, but then things we thought were fixed 
would happen again, so it was non-obvious if there was an intermittent bug, 
or a typo that went unnoticed that was critical.  We had no quality assurance 
aid to tell us that the data was Ok at any given point.

Many fields were populated in a way that was legal & proper on BPCS/36 but 
invalid on BPCS/400 - we had to identify them all & write small programs to 
populate them appropriately.  In some cases we had to substitute warehouse, 
item type, etc. values which involved many files, so we had to figure out the 
right sequence to fix files.

We abandoned the SSA conversion tool & went with an alternative for several 
reasons.  Here are the most critical.

Management also needed some technical training in how you do business with 
SSA.  They thought that the Help Line was supposed to help with all our 
problems, and balked at paying SSA Professional Services for more - where 
does this end, they wondered - if we reach something that SSA Professional 
Services cannot do, are we any closer to being live with BPCS/400 or just 
more out-of-pocket?

We have 4 divisions in 3 cities.  On BPCS/36 the MRP does not recognize 
distant warehouses - it thinks that since Arkansas has plenty of some raw 
material, Illinois does not need to order any.  For this reason we had 4 
BPCS/36 data bases, which are like 4 BPCS/400 environments - the software & 
data totally separate.  For a variety of reasons we wanted to combine our 
facilities into one environment.  SSA did not seem to have a conversion tool 
to combine multiple data sets into a consolidated arrangement.

Management wanted the company to get thru fiscal end-month on BPCS/36 then do 
the conversion over a weekend & be running the company on BPCS/400 the next 
Monday - we did in fact do that the weekend of August 1998, but that was not 
doable with the SSA conversion stream.

Of course, once we went to an alternative approach, we had gigantic 
flexibility that did not exist in the SSA conversion stream, so that we were 
able to extract the modifications that we had abandoned, and move that data 
into unused BPCS/400 fields, accessible through the external file layouts to 
query & much more.

The nature of our job-shop make-to-order business is such that there is a 
high turn-over of active parts, so that we constantly have large numbers of 
items routing BOM & other files with records coded for deletion, for which we 
had written modifications on BPCS/36 to accelerate purges for files with no 
vanilla purge support.  Conversion efforts involved using tapes from most 
recent fiscal end-month BPCS/36 to figure out how to get past various 
sticking points & we were disappointed that SSA conversion took deleted 
records all the way to the target.  In some cases, files might be 75% records 
that were deleted within the last year.

The SSA sizing questionnairre predicted how much disk space we would need to 
run BPCS/400 after conversion.  We were running BPCS/36 on the same machine 
while struggling with conversion efforts that might have copies of our files 
at Restore/36 point, 2.whatever, intermediate stages, target pilot testing, 
and several data bases at various points struggling through - learning stuff 
that was applied to others that got to that stage.  

The questionnairre had lacked the clarity to make allowance for disk space 
needed to do the conversion struggle, so of course we did not have enough 
disk space.  We had to off-load chunks of software & files to tape - go thru 
some steps, off-load chunks & reload from off-line, go thru some steps, churn 
what was on-line again.

Al Macintyre
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---