×
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.
Hello Booth, (?)
Am 24.11.2019 um 22:48 schrieb Booth Martin <booth@xxxxxxxxxxxx>:
With today's speeds and drill-downs the expandable subfile becomes, in my opinion, anachronistic.
On a side note, from a programmer's viewpoint, there's not much difference between a load-all vs. an expandable SFL. As soon as SFLPAG and SFLSIZ are different in value, it's always possible to expand the SFL programmatically to just add records.
So maybe it's anachronistic, but a few lines of code enable the hardware to finish this particular task faster (by stopping before EOF). I agree it makes not much difference in terms of absolute time until the screen arrives at the user's display. But when there are lot of users heavily using the SFL facility, the load of the machine is less.
Maybe somewhat more important but unknown to me if applicable to IBM POWER is that most "consumer grade" CPUs make extensive use of power saving facilities. Stuff the CPU doesn't need gets powered down in fractions of a second, and back up. So it's possible that an idle server with just SSDs consumes about 80W and if all cores are fully loaded with work, it's consuming 200W. If these 200W were drawn for a shorter amount of time because of more efficient programming, less energy is wasted. This makes not much of a difference seen for a single server in one small company. Seen globally with gazillions of machines, it would truly make a difference. Let me emphasize that I don't know if this is true with IBM POWER, too.
I'm somewhat appalled with this "we've enough CPU speed, so why invest in clever programming" attitude…
:wq! PoC
PGP-Key: DDD3 4ABF 6413 38DE -
https://www.pocnet.net/poc-key.asc
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.