Art:
It sounds like you already have the silver bullet you need.  If uptime and
availablity is a huge issue (it sounds like it is if you can't get the
machine to do a reorg), then a PC server solution is going to be much worse.
Carl

At 07:44 AM 11/6/97 -0500, you wrote:
>>         Art,
>>         It looks like you already have some data to back
>>         up staying with the 400.
>>         I'd suggest trying to find out all the areas they say
>>         it is slow, ie. Interactive too slow or daytime batch
>>         or overnight batch.
>>         If it is batch, then PC front-ends won't help near as
>>         much as a bigger 400.
>>
>
>This all started because users complained they needed another printer to
finish
>their jobs in time.  It turned out that they were having terrible response
>times.  We identified the problem as their main data entry program trying to
>write records to a 1 million record file, with approx 400,000 deleted
records,
>and REUSEDLT(*YES).  It took a long time to add records.  They could not
give us
>any downtime to run a RGZPFM, and we had to use REUSEDLT because our disk
usage
>was hovering around 90%.  We made some quick CLP changes to add records to
a work
>file, then add them in batch to the live file.  That solved that.
>
>>         Your user community might be some help too.
>>         You don't want to alienate the exec, but maybe
>>         someone besides you remembers why the got
>>         a 400. If the exec is being honest about not being
>>         hot for GUIs, what does he think he'll get with
>>         PCs and C/S ? I'd bet a fair number of the users
>>         entering all those transaction would hate to leave
>>         their green screens.
>>
>
>That is the question.  What will you get with C/S?
>
>>         From a purely financial side, don't forget these
>>         potential costs of C/S (not all will apply but
>>         some may):
>>         New PCs for those users who don't have them,
>>         Upgrade to users PCs to handle heavy transaction app.,
>>         Upgrade to network to support heavier C/S traffic,
>>         Training for users to learn new app.,
>>         Additional staff to support new app.
>>
>
>Booth mentioned the same cabling issue.  This one I hadn't thought of.
>
>>         Another way to justify new 400 costs is to divide
>>         by the number of users. Compare how much your
>>         client spends now per year, per person on PCs
>>         versus the AS/400. Unless all the users are on
>>         terminals the PC cost much more. Going to C/S
>>         tends to make the per person PC costs go even
>>         higher.
>>
>
>Another excellent point.  I know that they spend big bucks on their existing
>Novell/Sybase/Powerbuilder App.
>
>>         HTH & Good Luck
>>          -Steve Cotes
>>          -cotess@data-io.com
>
>Thanks!
>
>--
>Art Tostaine, Jr.
>Creative Computer Associates, Inc.
>Parlin, NJ
>atostaine_at_crecomp_dot_com
>
>
>+---
>| 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
>+---
>
Carl J. Galgano
http://cgalgano.home.mindspring.com
mailto:cgalgano@ediconsulting.com
EDI Consulting Services, Inc.   
540 Powder Springs Street
Suite C19
Marietta, GA 30064
770-422-2995
+---
| 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
+---


This thread ...

Follow-Ups:
Replies:

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

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