Mine too. Every time text is handled in significant amounts its obvious (variable length) record/line structure is found by searching for LF and/or CR and/or CRLF, then that information is *thrown away* as it is saved as formless mush, only for it to be found again next time.
Also seems to be the leading cause of Windows bugs, as far as I can make out--at least, I remember buffer overruns were named by MS as the commonest vulnerability. The main influence seems to be from 'C', which as far as I can tell was only designed for one job, to make writing the Unix OS easier than doing it in assembly--the idea of storing data in several MB of JSON was many years in the future, back then. I'm rewriting a bytecode interpreter to use on Linux and MVS 3.8j, so PL/I was the obvious choice with its CHAR VAR type and based structures. I'm very rusty at PL/I mind you :-) Roops On Mon, 28 Apr 2025, 11:48 Clement Clarke, <[email protected]> wrote: > Phil, my big bugbear is null terminated strings. Although there is little > or no difference in searching for nulls or LFs and CRs! > > IBM certainly got it right with PL/I strings, with the length of the string > up the front. Test after test I have done shows that null terminated > strings are a minimum of 3 times slower than doing it "properly". > > And VB record formats, of course. > > Just think of the speed lost and high electricity costs throwing all the > emails around the world every day! > > I actually spoke to Bill Gates about this decades ago, Notes etc are here: > https://start.oscar-jol.com/fast-safe-c-strings > > =================== > > I think there may be a way to make shuffling emails etc around the net a > bit better. Windows has various file types, such as .EXE, .JPEG, MP4 etc. > > Why not a file type of .VB? When the C Open routines see a filetype of VB, > it could start buffering strings just like ZOS does and creating blocks. > The GETS functions would not scan looking for CR, LF or nulls, but simply > transfer the record the the address in the GETS function. And transferring > data around the net would simply pick up the blocksize, and transfer the > block. > > Such a scheme would help get data around the internet more quickly. > > Cheers, > > > Clem Clarke > > > > > > > On Fri, Apr 25, 2025 at 11:40 PM Phil Smith III <[email protected]> wrote: > > > Luhn checksums. > > > > Barcodes weren't actually IBM: https://en.wikipedia.org/wiki/Barcode -- > > though the UPC version was. But as a refinement, I'm not sure that > counts. > > > > I think long-term compatibility should probably top the list. I have my > > "Time-machine List" of things in computing that were done wrong and that > > I'll fix when the machine works: > > - ASCII/EBCDIC (arguably this one is IBM's fault with the "ASCII bit" in > > S/360 and all that) > > - null-terminated strings > > - linends > > > > I'd add "more effort at maintaining compatibility across versions of > > things" but that's probably too broad. Or maybe not; there will be time, > I > > can always do it last week. > > > > -----Original Message----- > > From: IBM Mainframe Discussion List <[email protected]> On Behalf > > Of Bodra - Pessoal > > Sent: Friday, April 25, 2025 9:21 AM > > To: [email protected] > > Subject: RES: What has IBM ever done for us? (probably more than I know) > > > > Bar Code was another IBM innovation. > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
