RE: Left AS/400 and Returned

-----Original Message-----
From: Alan Campin [mailto:Alan.Campin@xxxxxxx]
Sent: Monday, May 02, 2005 4:04 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: MIDRANGE-L Digest, Vol 4, Issue 851


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.