Conversion from AS400 to WIndows

 17 Replies
 1 Subscribed to this topic
 11 Subscribed to this forum
Sort:
Author
Messages
mcurtis778
New Member Send Private Message
Posts: 0
New Member
I have an older database from release 6.1 (I beleive) from the AS400, and I am backing all of the files off into CSV files. The next step will be to import the data into A newer Windows based version of Lawson. My client has not yet bought the new Lawson so I am not able to get any technical support from Lawson. My question is, is there a conversion tool that Lawson has that will take my CSV files from the old Lawson system and convert them to the newer Windows based Lawson files? If not, what is the best way to map the files and fields from the CSV files ot the new Lawson files? Also, besides the data files, are there any files, besides the normal LAWDBF database files that I need to be aware of and bring over as well. I am sure that since the system I am coming from is so old that there will probably not be a perfect file for file and field for field mapping. I am not a Lawson expert, I am just trying to help my client get their old data into a new Lawson system without a lot of headache, work or money for them.

Thanks in advance

Mike
John Henley
Send Private Message
Posts: 3351
I would suggest you contact one of Lawson's partners, in particular CIBER, for some assistance in doing this. They may be able to help you do a table-to-table conversion via some of the upgrade programs in addition to the platform migration.

If that's not an option, you would need to dump all of the transactions, balance, master files, etc. into CSV from the 6.1 tables, and then reformat them to match the specs for the 8.x applications.
Thanks for using the LawsonGuru.com forums!
John
mcurtis778
New Member Send Private Message
Posts: 0
New Member
Thanks for the information. I will try to get in contact with CIBER to see if they can help. Otherwise I will need to get a list of the new files layouts so I can start planning some kind of conversion programs, probably written in java to try to get the files across. If there any other options I am open to them. I can also be reached at mcurtis778@yahoo.com.

Thanks
Alex Baltzer
New Member Send Private Message
Posts: 1
New Member
6.1 is a very old release and there is no path to upgrade. Lawson functionality and files had changed a lot since that release. I would suggest a load of data as a normal start up and if you want to have history, load it as historical transactions. In case of moving data from one system to another you need to take care of the EBCDIC / ASCII conversion.
Deleted User
New Member Send Private Message
Posts: 0
New Member
You're definately looking at a non-Lawson to Lawson conversion. As John said, you'd pull out the essential information (depending on what system codes you own) and then you're load them through the interface programs like you would any other non-Lawson system. Lawson provides conversion workbooks for all the system codes you're buying. If you're still in the sales cycle ask your sales person to get them for you so you can start planning.
PKS
Advanced Member Send Private Message
Posts: 23
Advanced Member

Helo Gurus,

My Customr is doing AS400 to Wndows migration along with upgrade

 

Their current version in 9.0.7 (Application ) . I am trying to setup source productline for Upgrade

 

Am unable to do sysload or appmetaload for meta data load 

Any Suggestions ??

Kwane McNeal
Veteran Member Send Private Message
Posts: 479
Veteran Member
This thread is 10 years old... If you want a serious response, you'll need to start a new one
PKS
Advanced Member Send Private Message
Posts: 23
Advanced Member

Thanks Kwane .

 

Didn't want to open a new thread as topic seemed relevant . I will open a new thread henceforth

We found a workaround for this .

Downloaded and installed the Lawson apps matching current Iseries version and we are proceeding

 

Kwane McNeal
Veteran Member Send Private Message
Posts: 479
Veteran Member
The issue you have is using this thread is that the versions discussed here in are ancient, and the method used to do the 6.x to 8.x is a reimplementation, whereas what you're doing is exactly what you found out... A copy, then an upgrade. There are a ton of pitfalls you'll run into. I just finished one of these last night, but I went the all-in-one route, by writing my own form of 'sqldbcopy' for multi-databases. My method is not for the faint at heart, but my client doesn't have the time window to allow for a full on copy then an upgrade.
PKS
Advanced Member Send Private Message
Posts: 23
Advanced Member

That's great . Doing straight upgrade.

This is my first project with AS400 hence lot of hiccups & questions . Thanks for quick response .

 

We have now build the copy product line . Tomorrow we are starting upgrade programs .

Hopefully thinks will run smooth

Kwane McNeal
Veteran Member Send Private Message
Posts: 479
Veteran Member
Are you using DB2 as your database for the Windows side also?
PKS
Advanced Member Send Private Message
Posts: 23
Advanced Member
No, we are using MSSQL
Kwane McNeal
Veteran Member Send Private Message
Posts: 479
Veteran Member
Then you have a long, painful, and definitely not smooth road ahead. Getting the data over is the straightforward part.
PKS
Advanced Member Send Private Message
Posts: 23
Advanced Member
That's not a good news . Could you share from your experience what are major pain points that are expected
Kwane McNeal
Veteran Member Send Private Message
Posts: 479
Veteran Member
That list is longer than you may realize. You may have issues with data conversion, speed, recreating system processes, etc. If your thought was to create a product line on Windows and connect it to the iSeries, and follow the upgrade guide, you won't get far. Nearly nothing will work correctly when you're finished, if those jobs even can finish. Sqldbcopy won't work (that's why I wrote my own), dbcopy also will fail on most tables in financials. Forget even trying the environment migration guide. You'll have to do most of it by hand. I don't have enough info on how you plan to do it, so there are areas I can't speak to in a general forum. Let's just say that there is a reason most data transformation tools can't even connect to db2 on an iSeries, let alone get data out of it. I can't give specifics on implementation, as the clients I work with wouldn't appreciate me giving that info away for free, considering the costs to them to figure all of this out. You're welcome to contact me privately on this forum if you want to share your implementation specifics, and I'll give you feedback on your approach. If you need more, we'll have to setup a more formal arrangement.
PKS
Advanced Member Send Private Message
Posts: 23
Advanced Member

Thanks Kwane .

I think we are already on the bumpy road you warned .

We are using ICS tool to do the migration so most part it was fine .We have setup 901 source as new sql DB .We faced two major hiccups .

 Performance was  very slow for huge tables - 50 million records so we actually ended up using SSIS tools for 20+ tables . For the rest we used ICSTools.

Second was default date conversion (01-01-0001 to 01-01-1753) and we had to dealt with some corrupt date records in Iseries.

 

Kwane McNeal
Veteran Member Send Private Message
Posts: 479
Veteran Member
Yes. Plus I had to deal with the time field, which has no equivalent. The large tables, my tool does some pretty nasty cursor logic to allow for parallel processing, because I ran into exactly what you're discussing. Heck, in tuning the connection, I killed the SQL Server engine completely a few times. On the 901 side, didn't have to do that, as I used the original dictionary, but that was fraught with pain and suffering. I also had to code logic to ignore iSeries specific features in the PL. All in all, messy. How did you handle username conversion in the data?
PKS
Advanced Member Send Private Message
Posts: 23
Advanced Member
Yes , I missed to mention about time as well . We had to take care of that in SSIS as well. We had tried to build the dictionary using sysdump , appmetaload etc but could not succeed so we actually downloaded windows app matching their 9.X version and imported the data . For now we have not handled the username in the application data . We had to deal with 20+ users when we did environment data . This is more of a sandbox and is to be used by IT only . We are looking post conversion update for smaller tables and tweaking SSIS tool for Big Tables.