|
Walden You may have missed the original thread, started by Scott Cornell - "it's not just the box dummy - it's just a house of cards." The ability to move displays, etc.. into production without downtime is only one part of that and this thread. Part of my response to Scott's original post was that if you put the rules in the same database as the data to which they apply, rather than in programs as at present, then you could change the database structure in real-time, whilst applications are live. I have implemented such a solution which I call a Neural Database. Both the productivity gains for development and the response times in production are stunning. Changing the database structure in real-time has no impact on the response times of other users of the database. In addition, you are using much fewer cpu cycles for compilation. No upgrade is required. Your managers can laugh all the way to the bank. Rob Dixon ---------- > From: Walden Leverich <walden@techsoftinc.com> > To: MIDRANGE-L@midrange.com > Subject: RE: Design shift of view > Date: 28 July 1998 17:54 > > This thread has taken an interesting academic twist. Let us all remember > that we work for companies that are in the business to make money > (non/not-for profit excluded). So, yes machines are faster, but still > not fast enough. Imagine presenting to your management that you want to > spend 100K on an AS/400 upgrade and your users won't see any performance > improvement. (AKA, selling V3Rx to a V2Rx company) All the company will > get from this upgrade is the ability to move programs/display/physicals > into production without any downtime. While some managers (very few) > might bite, the rest would laugh you out of the office. Or to put it > another way, how would you like B50 performance from your brand-spanking > new 620? > > Now, I don't disagree that display/print files should be changeable with > a RPLOBJ option, just like programs, but to take the concept to the > database is going to far, IMHO. I'd love it, but the machine performance > isn't there yet. And remember, the RPLOBJ option on a program compile is > a happy side effect to the fact that once a name is resolved the program > is called again via its pointer, not via its name. So we tell the > program object that it is in QRPLOBJ now, not PRDPGMS and away we go. We > aren't actually moving the program, but counting on the fact that it > doesn't move. > > -Walden +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | 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.