× 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.








>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 thread ...

Follow-Ups:

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.