The cost to the fixed length fields and records is padding with blanks. That results in streaming files having a 2/1 compression ratio and fixed length files having a 4/1 ratio.
On Sun, Feb 12, 2023 at 12:34 PM Hobart Spitz <orexx...@gmail.com> wrote: > > IMHO, the fault lies in the character stream orientation of UNIX, C, HTML > etc. The shorted-sighted design was motivated by the limited budgets and > underpowered systems of many early UNIX users. > > On record oriented systems, (z/OS and z/VM) common operations are faster, > because the needed information is not embedded in the data. For example: > > - Read/skip-to the next record. > - Find/check the length of a string. > > On byte stream oriented systems, every single character, including the > otherwise uninteresting ones, must go through the CPU for such operations. > Record oriented systems can efficiently add the record length to the > current record address, or compare a target character position to the > length of the record to avoid string overflow (e.g). > > It doesn't help that most character oriented systems use 16 bit characters > whereas most work on zSeries is done with 8-byte characters. The workload, > all other things being equal, is essentially doubled. As stated above, all > other things are anything but equal. > > Note that UNIX (etc.) systems originally used 4K buffers between pipe > stages; Most such systems now use 64K buffers to support the heavy load of > characters run through the CPU and to reduce costly redispatching. > > It may be related that IBM went from two cache levels to four about the > time USS was added. More hardware manufacturing and heat generation > resulted. > > Unfortunately this mistake is so pervasive that it might never be fixed. > The impact is not just on electricity usage, but also on global warming and > climate change due to extra cooling and extra hardware. > > Anyone who understands that global warming and climate change are > existential threats and that it may be too late to avoid catastrophic > impacts would be well advised to keep their record oriented systems and > move away from UNIX, Linux, and Windows where feasible. > > Just my "buck three eighty", or two cents if you prefer. > > OREXXMan > Q: What do you call the residence of the ungulate with the largest antlers? > A: A moose pad. > :-D > Would you rather pass data in move mode (*nix piping) or locate mode > (Pipes) or via disk (JCL)? Why do you think you rarely see *nix commands > with more than a dozen filters, while Pipelines specifications are commonly > over 100s of stages, and 1000s of stages are not uncommon. > REXX is the new C. > > > On Sat, Feb 11, 2023 at 8:37 PM Bill Johnson < > 00000047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > > Correct. I copied the article from the NYT & then reposted the paragraph > > in the article which discussed the study. > > > > > > > > Heh - I don't think those are rankings - just (former) links from the > > article in whatever publication Bill copied from. > > > > > > > > ... > > > >The largest cloud data centers, sometimes the size of football fields, > > > are owned and operated by big tech companies like Google, Microsoft, > > Amazon > > > and Facebook. > > > > ... > > > >Over the years, data center electricity consumption has been a story of > > > economic incentives and technology advances combining to tackle a > > problem. > > > > > > > Do they use: > > > o IBM z? > > > o IBM supercomputers? > > > o Others, such as overseas-sourced (specify)? > > > > > > > At one time Facebook published detailed specs for its homegrown PC servers, > > in contrast to the likes of Google, Amazon, and Microsoft, for whom it's > > all trade secrets. I've no idea if they've kept the specs current. Lynn > > Wheeler wrote about this stuff a number of times when he was active on > > IBM-MAIN, though mostly from an available-compute-power perspective rather > > than a power efficiency one. > > > > Tony H. > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
