|
>The problem is that the 400 is slow, and they need a solution. The MIS exec has >all but convinced my previously happy client that they need to "offload" some >applications from the AS/400. Get some things down to the PC's. > >I said that if they wanted GUI, we could do that easier than writing our own >front end, using seagull, BOS, etc. > >MIS exec says, "I'm not real hot on GUI, I just want to save the AS/400 some CPU >cycles" > >Why? Why take an application that works, but is slow, and rewrite it, re-test, >etc., on a PC? > >They do not want to spend money to upgrade the AS/400, but will rewrite >applications on a PC! > >It has only taken 5 years for the customer to forget the nightmare that was their >PC network. In fact, the PC software company that is waiting (drooling) to write >all of these new applications is the one that was responsible for the old >network! We replaced them, now their waiting do replace me! Don't you just love this? There is a complete fallacy in the MIS exec's position by saying I don't way to spend money on upgrading the AS/400 but will spend money to save CPU cycles by offloading the code. That position is self defeating - as I'm sure you are aware of. 1.)Given that there are no application enhancements - why would someone want to spend money on software as opposed to processing power? Given the choice, the logical decision is to get the processing power. 2.) Given that there are application enhancements - is the risk involved in going from a stable application environment to the unknown worth it? I don't know about you but hardware upgrades (except for the occasional CISC to RISC) are pretty darn stable and easy to predict when they will be complete. 3.) Any precise measurements on what CPU cycles will be offloaded? My guess is that no one including your PC software company can estimate that. What if the guestimate is inaccurate? Is the risk and the dollars worth spending to find out? 4.) Are all costs being reviewed? My guess is that you will see soft and hidden costs go up that are not even being included. Look for changes in the PC environment.... run time code, change control, hardware upgrades, PC's vs. terminals, etc. 5.) Another risk is possibly the split of application logic. Depending on how the application is broken up may make maintenance tough. If I make this change here what will happen there? If the design is to use the AS/400 as a database server your risk is minimized. 6.) Given that a PC LAN environment is inherently less stable than a terminal green screen environment how will database integrity be maintained? 7.) Powerbuilder? People still write in Powerbuilder? :-) 8.) Despite writing the above - you could join them.......If you want an easy way to start writing C/S code I would take a long hard look at Magic/400. It is a wonderfully robust and fairly easy to learn development environment. I don't use the product but have demo'd it....it seems pretty neat. Looking at it I don't know if I would ever write mainline C/S applications in Powerbuilder, VB, VRPG, etc. Now, I am not a C/S developer by any stretch but I do use the above products. HTH +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to "MIDRANGE-L@midrange.com". | To unsubscribe from this list send email to MAJORDOMO@midrange.com | and specify 'unsubscribe MIDRANGE-L' in the body of your message. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
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.