Re: NOTSP The Latin of Software Code Is Thriving - The New York Times
On 12/07/2022 12:21 am, Charles Mills wrote: +1 And when new hardware comes out, taking advantage of the new architecture is a simple matter of updating ARCH() in your C/C++ compile and re-building. You probably don't have the appetite to re-work your carefully hand-tuned assembler. +1 you can't optimize for hardware that hasn't been invented yet I know whereof I speak. I wrote a commercial product in C++ that successfully handled millions of events per second, with CPU utilization that was considered satisfactory by customers. Non-trivial events: basically taking an SMF record, reformatting a hundred or more fields using a "report writer"* type architecture, translating it to UTF-8 (non-trivial) and pushing it out the TCP stack. *By report writer type architecture, I mean it did not work the way you would write a hard-coded program, working its way through one SMF record section at a time. It went customer-specified-field by customer-specified-field, so for two adjacent fields in the same section, it had to decode the relevant triplet twice. We can easily push millions of events through our stack which is written in Metal/C and Java. https://www.ibm.com/docs/en/om-im/5.6.0?topic=monitor-getting-started Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andrew Rowley Sent: Sunday, July 10, 2022 6:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: NOTSP The Latin of Software Code Is Thriving - The New York Times On 9/07/2022 1:10 am, Colin Paice wrote: I was told If it executes 1. a million times a second - write in assembler 2. a thousand times a second write it in cobol or C 3. once a second - write it in Java 4. Else /bash/rexx/ Probably not an accurate picture these days. It would have to be a very select piece of assembler to have any significant advantage over C / C++. C and C++ have the advantage that the compiler doesn't have to produce maintainable or comprehensible code, so it can do lots of optimizations, inlining, loop unrolling etc. - whatever the compiler writers found produces the fastest code. Of course you can do the same in assembler - it is just a question of whether it is practicable for larger pieces of code. Java: that is probably reasonable if you are talking about starting a JVM from scratch every time e.g. like a z/OS batch job. If you are talking about a routine executed by a running program, I would expect Java to be close to C. (Certainly not 3 orders of magnitude different.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NOTSP The Latin of Software Code Is Thriving - The New York Times
My comments about 1. A million times a second... etc Were from about 30 years ago, before optimization improved. I know that the "hot" instruction for MQ on z/OS that showed up in profiling, was the Load/Update Address of the next free slot in the trace buffer in ECSA. When there were many concurrent threads using MQ trace, they all used this field. Sometimes the field was on the same chip. Sometimes it was in a different "book" (and so the time to get this field was 1000 times the duration if it was in the same CPU) By giving each TCB its own trace buffer this hotspot disappeared! The compiler could not optimize this. Only a change of design could fix it. Colin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NOTSP The Latin of Software Code Is Thriving - The New York Times
+1 And when new hardware comes out, taking advantage of the new architecture is a simple matter of updating ARCH() in your C/C++ compile and re-building. You probably don't have the appetite to re-work your carefully hand-tuned assembler. I know whereof I speak. I wrote a commercial product in C++ that successfully handled millions of events per second, with CPU utilization that was considered satisfactory by customers. Non-trivial events: basically taking an SMF record, reformatting a hundred or more fields using a "report writer"* type architecture, translating it to UTF-8 (non-trivial) and pushing it out the TCP stack. *By report writer type architecture, I mean it did not work the way you would write a hard-coded program, working its way through one SMF record section at a time. It went customer-specified-field by customer-specified-field, so for two adjacent fields in the same section, it had to decode the relevant triplet twice. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andrew Rowley Sent: Sunday, July 10, 2022 6:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: NOTSP The Latin of Software Code Is Thriving - The New York Times On 9/07/2022 1:10 am, Colin Paice wrote: > I was told > If it executes > > 1. a million times a second - write in assembler > 2. a thousand times a second write it in cobol or C > 3. once a second - write it in Java > 4. Else /bash/rexx/ Probably not an accurate picture these days. It would have to be a very select piece of assembler to have any significant advantage over C / C++. C and C++ have the advantage that the compiler doesn't have to produce maintainable or comprehensible code, so it can do lots of optimizations, inlining, loop unrolling etc. - whatever the compiler writers found produces the fastest code. Of course you can do the same in assembler - it is just a question of whether it is practicable for larger pieces of code. Java: that is probably reasonable if you are talking about starting a JVM from scratch every time e.g. like a z/OS batch job. If you are talking about a routine executed by a running program, I would expect Java to be close to C. (Certainly not 3 orders of magnitude different.) -- Andrew Rowley Black Hill Software -- 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
Re: NOTSP The Latin of Software Code Is Thriving - The New York Times
On 9/07/2022 1:10 am, Colin Paice wrote: I was told If it executes 1. a million times a second - write in assembler 2. a thousand times a second write it in cobol or C 3. once a second - write it in Java 4. Else /bash/rexx/ Probably not an accurate picture these days. It would have to be a very select piece of assembler to have any significant advantage over C / C++. C and C++ have the advantage that the compiler doesn't have to produce maintainable or comprehensible code, so it can do lots of optimizations, inlining, loop unrolling etc. - whatever the compiler writers found produces the fastest code. Of course you can do the same in assembler - it is just a question of whether it is practicable for larger pieces of code. Java: that is probably reasonable if you are talking about starting a JVM from scratch every time e.g. like a z/OS batch job. If you are talking about a routine executed by a running program, I would expect Java to be close to C. (Certainly not 3 orders of magnitude different.) -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NOTSP The Latin of Software Code Is Thriving - The New York Times
> Am 08.07.2022 um 17:10 schrieb Colin Paice : > > I was told > If it executes > > 1. a million times a second - write in assembler > 2. a thousand times a second write it in cobol or C > 3. once a second - write it in Java > 4. Else /bash/rexx/ > > Though if it executes once a year and runs for a week- I might look at C As intriguing - and easy to memorize! - such listings are, they may quickly become totally misleading. E.g. Java has become able to run as quick as C/C++ and sometimes even faster than C/C++! One aspect that should be stressed in this context: given the ever ongoing improvements in hardware and software infrastructures benchmarks - if deemed important nowadays :) - need to be redone on a regular (yearly) basis. One interesting - REXX-related - table about speed improvements of different REXX/Rexx implementations over the decades can be found at the website of the father of REXX - Mike F. Cowlishaw - at: http://speleotrove.com/misc/rexxcpslist.html Looking at these numbers (I do not know of any comparable historical table for other programming languages using the same benchmark program throughout the decades on different implementations of a language) one can see how breathtaking the technical improvements have been over the decades: going from 114 RexxCPS in 1994 to 23,774,392 (!) RexxCPS in 2021. So in 2021 Rexx programs would execute roughly 220,000 times (!) faster than in 1994! —-rony >> On Fri, 8 Jul 2022 at 15:52, Dave Jones wrote: >> >> Timothy Sipples said: >> >> "Which leads to an interesting thought exercise. In 2022 if you're trying >> to choose a programming language for business application programming that >> stands the best chance of being durable (being realistically maintainable, >> extendable, enhance-able) for the next 40+ years — a common requirement for >> many high value, nontrivial business applications — what programming >> language would you choose? I suggest Enterprise COBOL ought to be a >> candidate. (Any other nominations?)" >> >> Enterprise PL/I, of course. :-) >> DJ >> >> -- >> 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
Re: NOTSP The Latin of Software Code Is Thriving - The New York Times
Enterprise PL/I -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Spiegel Sent: Friday, July 8, 2022 10:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: NOTSP The Latin of Software Code Is Thriving - The New York Times +1 On 2022-07-08 10:51, Dave Jones wrote: > Timothy Sipples said: > > "Which leads to an interesting thought exercise. In 2022 if you're trying to > choose a programming language for business application programming that > stands the best chance of being durable (being realistically maintainable, > extendable, enhance-able) for the next 40+ years — a common requirement for > many high value, nontrivial business applications — what programming language > would you choose? I suggest Enterprise COBOL ought to be a candidate. (Any > other nominations?)" > > Enterprise PL/I, of course. :-) > DJ > > -- > 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
Re: NOTSP The Latin of Software Code Is Thriving - The New York Times
+1 On 2022-07-08 10:51, Dave Jones wrote: Timothy Sipples said: "Which leads to an interesting thought exercise. In 2022 if you're trying to choose a programming language for business application programming that stands the best chance of being durable (being realistically maintainable, extendable, enhance-able) for the next 40+ years — a common requirement for many high value, nontrivial business applications — what programming language would you choose? I suggest Enterprise COBOL ought to be a candidate. (Any other nominations?)" Enterprise PL/I, of course. :-) DJ -- 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
Re: NOTSP The Latin of Software Code Is Thriving - The New York Times
I was told If it executes 1. a million times a second - write in assembler 2. a thousand times a second write it in cobol or C 3. once a second - write it in Java 4. Else /bash/rexx/ Though if it executes once a year and runs for a week- I might look at C Colin On Fri, 8 Jul 2022 at 15:52, Dave Jones wrote: > Timothy Sipples said: > > "Which leads to an interesting thought exercise. In 2022 if you're trying > to choose a programming language for business application programming that > stands the best chance of being durable (being realistically maintainable, > extendable, enhance-able) for the next 40+ years — a common requirement for > many high value, nontrivial business applications — what programming > language would you choose? I suggest Enterprise COBOL ought to be a > candidate. (Any other nominations?)" > > Enterprise PL/I, of course. :-) > DJ > > -- > 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
Re: NOTSP The Latin of Software Code Is Thriving - The New York Times
Timothy Sipples said: "Which leads to an interesting thought exercise. In 2022 if you're trying to choose a programming language for business application programming that stands the best chance of being durable (being realistically maintainable, extendable, enhance-able) for the next 40+ years — a common requirement for many high value, nontrivial business applications — what programming language would you choose? I suggest Enterprise COBOL ought to be a candidate. (Any other nominations?)" Enterprise PL/I, of course. :-) DJ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NOTSP The Latin of Software Code Is Thriving - The New York Times
LOL, I really enjoyed this. I've probably posted it here before, but an old joke: Jack was a COBOL programmer in the late 1990s who (after years of being taken for granted and treated as a technological dinosaur by all the UNIX programmers and Client/Server programmers and website developers, etc) was finally getting some respect. You see, he'd become a private consultant specializing in Year-2000 conversions. He was working short-term assignments for prestigious companies, traveling all over the world on different assignments. He was working 70- and 80- and even 90-hour weeks, but it was worth it. However, several years of this relentless, mind-numbing work had taken its toll on Jack. He had problems sleeping and began having anxiety dreams about the year 2000. It had reached a point where even the thought of the year 2000 made him nearly violent. He must have suffered some sort of breakdown, because all he could think about was how he could avoid the year 2000 and all that came with it. By the end of 1997 Jack had decided to contact a company that specialized in cryogenics. He made a deal to have himself frozen until 2001 through their totally automated (and very expensive) process. He was thrilled. The next thing he would know, he'd wake up in the year 2001 -- after the New Year celebrations and computer debacles, after the leap year, and after the dust had settled. Nothing else to worry about except getting on with his life. He was put into his cryogenic receptacle, the technicians set the revive date, he was given injections to slow his heartbeat to a bare minimum, and that was that. The next thing Jack saw was an enormous and very modern room filled with excited people. They were all shouting "I can't believe it!" and "It's a miracle" and "He's alive!". There were cameras (unlike any he'd ever seen) and equipment that looked like it came out of a science fiction movie. Someone who was obviously a spokesperson for the group stepped forward. Jack couldn't contain his enthusiasm. "It's over?" he asked. "Is 2001 already here? Are all the millennial parties and promotions and crises all over and done with?" The spokesman explained that there had been a problem with the programming of the timer on Jack's cryogenic receptacle. It hadn't been year-2000 compliant; it was actually 8000 years later, not the year 2001. But the spokesman told Jack that he shouldn't get excited; someone important wanted to speak to him. Suddenly a wall-sized projection screen displayed the image of a man that had a striking resemblance to Bill Gates. This man was Prime Minister of Earth. He told Jack not to be upset. That this was a wonderful time to be alive. That there was world peace and no more starvation. That the space program had been reïnstated and there were colonies on the moon and on Mars. That technology had advanced to such a degree that everyone had virtual-reality interfaces that allowed them to contact anyone else on the planet, or to watch any entertainment, or to hear any music recorded anywhere. "That sounds terrific," said Jack. "But I'm curious: Why is everybody so interested in me?" "Well," said the Prime Minister. "The year 10,000 is just around the corner, and it says in your files you know COBOL..." --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* I drive 'way too fast to worry about cholesterol. -Anonymous */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Timothy Sipples Sent: Friday, July 8, 2022 01:37 It's *so* weird! Imagine writing this: "Sarah, age 23, rejected her college advisor's career advice and started work at Boeing in Seattle last year. Her friends who mainly pursued careers in banking and law outright laugh at her for designing airplanes, the antiquated vehicles invented well over a century ago. But Sarah takes their ribbing in stride even as she works on designs that past generations of engineers could mostly comprehend." Or this: "Last night Olivia Rodrigo won the 2022 GRAMMY for Best New Artist. It's ironic that the Recording Academy uses the word 'new' to describe any award they hand out. Audio recording was invented all the way back in the 1800s with only modest incremental improvements since. And it's particularly galling that Rodrigo has never publicly thanked Thomas Edison and other music recording pioneers for contributing to her success in the ancient industry she chose. Of course everyone knows music is dying. One analyst in Ecuador predicts that within 10 years the number of people who listen to music at least once per day will fall by 92.4%." Here's how I think of programming languages. There's a very short list of programming languages that are both so common, so useful, and (relatedly) so adaptable (incrementally improved, integrated, extended, etc.) that they have (for all intents and purposes) achieved "immortality." COBOL is definitely on this distinguished short list. Other things being eq
Re: NOTSP The Latin of Software Code Is Thriving - The New York Times
It's *so* weird! Imagine writing this: "Sarah, age 23, rejected her college advisor's career advice and started work at Boeing in Seattle last year. Her friends who mainly pursued careers in banking and law outright laugh at her for designing airplanes, the antiquated vehicles invented well over a century ago. But Sarah takes their ribbing in stride even as she works on designs that past generations of engineers could mostly comprehend." Or this: "Last night Olivia Rodrigo won the 2022 GRAMMY for Best New Artist. It's ironic that the Recording Academy uses the word 'new' to describe any award they hand out. Audio recording was invented all the way back in the 1800s with only modest incremental improvements since. And it's particularly galling that Rodrigo has never publicly thanked Thomas Edison and other music recording pioneers for contributing to her success in the ancient industry she chose. Of course everyone knows music is dying. One analyst in Ecuador predicts that within 10 years the number of people who listen to music at least once per day will fall by 92.4%." Here's how I think of programming languages. There's a very short list of programming languages that are both so common, so useful, and (relatedly) so adaptable (incrementally improved, integrated, extended, etc.) that they have (for all intents and purposes) achieved "immortality." COBOL is definitely on this distinguished short list. Other things being equal it's a great characteristic when you're making investment choices including career choices. It just doesn't matter that (for example) the C programming language was ostensibly born circa 1969 (with an earlier implementation, the B programming language) and COBOL was first specified in 1960. If in 2022 you want to assign any significance to a ~9 year difference in birth dates to make some sort of utility argument then you're (in a word) crazy. The C programming language is another entry on the distinguished short list, but it just so happens it's a pretty awful programming language for most business application programming. Which leads to an interesting thought exercise. In 2022 if you're trying to choose a programming language for business application programming that stands the best chance of being durable (being realistically maintainable, extendable, enhance-able) for the next 40+ years — a common requirement for many high value, nontrivial business applications — what programming language would you choose? I suggest Enterprise COBOL ought to be a candidate. (Any other nominations?) — — — — — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM zSystems/LinuxONE, Asia-Pacific sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NOTSP The Latin of Software Code Is Thriving - The New York Times
Drives me nuts! If someone wanted a career in automotive technology, no one would run cutesy articles talking about hundred-year-old technology. UNIX is fifty-plus years old for gosh sakes -- about five years younger than the System 360. Would it be cute if some 24-year-old wanted to work with fusty old UNIX? I guess that is the fusty old code that is baked into iPhones? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gabe Goldberg Sent: Wednesday, July 6, 2022 12:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: NOTSP The Latin of Software Code Is Thriving - The New York Times Next time you laugh at musty old tech, remember that new technologies are often built on it. Caitlin Mooney is 24 years old and infatuated with technology that dates to the age of Sputnik. Mooney, a recent New Jersey Institute of Technology graduate in computer science, is a fan of technologies that were hot a half-century ago, including computer mainframes and software called COBOL that powers them. That stuff won’t win any cool points in Silicon Valley, but it is essential technology at big banks, insurance companies, government agencies and other large institutions. During Mooney’s job hunt, potential employers saw her expertise and wanted to talk about more senior positions than she was seeking. “They would get really excited,” Mooney told me. She’s now trying to decide between multiple job offers. The resilience of decades-old computing technologies and the people who specialize in them shows that new technologies are often built on lots of old tech. When you deposit money using your bank’s iPhone app, behind the scenes it probably involves computers that are the progeny of those used in the Apollo moon missions. (Also, half-century-old computer code is baked into the iPhone software.) It’s often seen as a problem or a punchline that so much musty technology is still around. But it’s not necessarily an issue. https://www.nytimes.com/2022/07/06/technology/cobol-jobs.html?smid=url-share -- 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
