× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.









As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

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