Re: MIDRANGE-L Digest, Vol 4, Issue 851 -- MIDRANGE-L

Two reasons not to have a well designed database in the AS/400:

1-It has been working since the days when the DB2/400 was quite primitive (and m$ didn't exited yet) 2-The AS/400 programmers are beginers or not up to date. _________________________________________________________________________ Alan Campin wrote:

Sorry, I have to report the opposite.
Our company several years ago dumped AS/400 based Payroll and Financials because it took forever to get any changes done and went to a C# and SQL based packages and I am astounded at the quality of these applications vs. what I see on an AS/400, the most important one being that they actually have normalized data base and they obviously have people who understand what a data base is.

I have never seen an application package on the AS/400(and I have worked with a lot) with a normalized database and every company I ever worked with did not have one person working for the applications company who knew what the hell a normalized data base was. One company had thousands of programmers and I am not sure they even knew there was a data base on the 400.

The other part of it is that they have a fraction of the code in AS/400. Almost all the code is written in SQL Stored Procedures and compared to the bazillions of programs I see in the average AS/400 application package, they have almost nothing and they have features why ahead of anything I have seen on AS/400 packages.

My experience has been that if you look at the average AS/400 applications package, you are going to find that half to 3/4 of the code is written to do nothing except deal with database anomaly's. In contrast, every time I have written a system with a normalized database, the amount of code to write is small and clean.

I not saying the package is perfect. Just way ahead AS/400 products I have seen.

Now the down side, it runs on Microsoft and that means you have one person spending all her time dealing with instability of Microsoft products but I guess you have to contrast that with having 3 or 4 full time AS/400 programmers maintaining and trying to enhance the AS/400 product. The product itself is fine. The problem is the underlying Microsoft technologies they have to rely on.
So my questions, why the hell can't we write an applications that clean on the 
AS/400? We do we have to continue writing 10,000 line monolith programs to deal 
with abnormal databases?
Message: 6 date: Mon, 2 May 2005 14:44:27 -0400 from: "Jim Hawkins" <jim.hawkins@xxxxxxxxxxx> subject: RE: Left AS/400 and Returned

Several years ago a company I worked for moved their HR/Payroll applications from an AS/400 to an Intel based application (GUI and "security" were the reasons-course IT knows nothing). 9 months later we moved back to the AS/400 based application. The payroll clerk went from taking most Friday's as a vacation day under the /400 solution (she had been there forever) to working 70+ hours a week and no vacation time under the Intel based solution. Data was constantly being lost by the system, nothing ever tied out, the different PC's could never communicate with the server with the central database and processing payroll took at least twice as long. That's not to mention dedicating one IT team member about half time to keep the application running. The AS/400 application had very little IT support required. Support for the Intel application was horrible. A fix might break 10 other things and take 2-3 weeks to given to us. Help desk seemed to take their time returning calls. The payroll clerk suffered from an infection shortly after the Intel system.