Mark (and George), the technique was widely (and badly) used back in the old days when memory was expensive and machines were a lot slower. I responded to your email, Mark, because I was thinking of your older, slow systems; I wanted to remind you of the inefficiency because I remember that when I rewrote one invoicing application that had used the OCONV(Tfile) form extensively, and did a single Open and Read of the necessary records, the procedure went from taking 1 hour to under 15 minutes. The only change in the program logic was the elimination of the multiple OCONVs, and the batch sizes were relatively consistent, so it was processing the same number of records.
I was told at the time that the ENGLISH process implemented the Open/Read logic differently and was much more efficient, so OCONV(Tfile) in a dictionary was ok, but should not be used in a Basic program. I am delighted to hear that the implementation of the OCONV(Tfile) in Basic has been improved - and if it has been improved in _a_l_l_ current versions of Pick, I withdraw my objection to it. Until then, I will avoid it on the off chance that my code will be put on a box where the implementation is not geared toward optimizing that particular construct. Bottom line: even if hardware and O/S software are much faster now, and the difference between good and bad code is not so easy to detect in terms of speed for various processes, why waste resources the stockholders have spent good money on by not optimizing the code (unless it greatly increases the cost of development or maintenance)? Susan Lynch F.W. Davison & Company, Inc. ----- Original Message ----- From: "George Smith" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, October 21, 2005 9:45 AM Subject: Re: [U2] Translate question > My understanding is that any contemporary platform caches files opened with > an OCONV so that, with sufficient memory, there is basically no performance > hit. This is certainly true on the mvBase and REALITY systems I support. The > old MCD systems didn't have 'sufficient memory' of course, so we worried > about it. > byw, the current version of REALITY is very nice, and if you actually still > have clients on MCD/McDonnell Douglas hardware, you might want to suggest a > migration. Reality to Reality is painless. > George Smith > Phoenix, AZ > > On 10/20/05, Mark Johnson <[EMAIL PROTECTED]> wrote: > > > > Oddly enough I learned this back in the day on microdatas (I used to work > > for MCD in the late 1970's) and have been using it ever since. > > > > I find it much easier to program than the OPEN/READ for the simple > > purposes. > > I'm obviously effeciency oriented and wouldn't OCONV more than 1 field. My > > brain detects the need for the second field and I program OPENs and READs. > > > > I spent 2 days with my MCD clients last week and it's getting painfully > > obvious how slow it is. The absense of indexing is perhaps the greatest > > loss. I have to be far more concerned for effeciency. > > > > On D3 and U2 systems, one doesn't have to be perfectly effecient. Before > > everyone gets on their soapbox and flames me for not being perfect, > > understand that people like me have lived on both sides, native and > > contemporary. > > > > The native systems never had the speed and were about 30% less on other > > advanced features. I can honestly say that upgrading to a faster box > > brings > > with it more application opportunites that may have been declined on the > > prior system. There are things you can do on a current system that would > > be > > a burden on an older system. But effecient methods brough forth from a > > system with less resources to a current system wins both times. > > > > I've not felt the delay during these past 25 years of using OCONV for > > single > > readv's, old or new systems. That's just my experience. > > > > Thanks > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
