|
Bob Cozzi wrote: (P.S. Congratulations on being elected to the board of COMMON Bob! - or should that be commiserations ;-) >I realize that the Toronto lab is not responsible for the DATE problem. >But over the years, Rochester has "fixed" a lot of things that Toronto >should have corrected. Since Toronto is doing a lot of great things >lately, perhaps it's time for pay back. <g> I don't recall anything that Rochester "fixed" for us so you'll have to enlighten me on that one of these days. However, we are doing some work on the parts of the date ops that we can affect (i.e. those directly related to the RPG IV date ops etc.) and I've been hearing good things out of Rochester with regard to performance improvements down at the microcode level that improve the performance. Not to mention the fact that they will at last be usable on display files etc. That said - I'm with John Carr on this one - other than in exceptional circumstances - dates pay for any performance penalty in improved ease of use both at the programmers and at the end-user level. You never have to worry about a bad date in anything that you process - if it was bad it would never have made it into the database! +--- | 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-2025 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.