date:20240222

Dedicated fax machines, combo printer/scanner/fax or wokstations with fax 
modems?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Gibney, Dave <03b5261cfd78-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, February 22, 2024 7:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Very much off-topic] Re: AI is the real deal.

Fax machines are still heavily used un medical and legal areas

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of zMan
> Sent: Thursday, February 22, 2024 4:06 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [Very much off-topic] Re: AI is the real deal.
>
> [EXTERNAL EMAIL]
>
> The FAX machine's impact wasn't exactly tiny. Short-lived, yes.
>
> On Thu, Feb 22, 2024 at 7:04 PM Dave Beagle < 0525eaef6620-dmarc-
> requ...@listserv.ua.edu> wrote:
>
> > Picking on Krugman is typical of the right. But, that’s not exactly
> > what he said. Here’s the context.
> >
> >
> >
> https://secure-web.cisco.com/1CieSMPaZwvATHo3u6SeKwdTSLYWjrgzgHMj5G0cgeCU6OwRX-tYZ0dZywGFgIYxZ06npUpn5PdldAbPxondPyUXiudafJL2BDmpgDe6rIweSl28zsyyk2d3NIj-xPIx6hsP1J7Opb2qapLGK-iUSprkRmplH8sgKkH2Fa_GDPo3s5-6nMxBfty_xI1VeBOk3eZA2jCA0T-lEW75Uwsp9gT2BVKTGHZRysd2x6abN4KAFeZTovDz9zsB5F5HQrDt9snuZo7CYjPBb6oBbE3fHDt6B9Abfd4xRxhiXU5O_bnWnTmtJPekKqEj5EtxQBmN-0SFI7HoHDQAVGFH-ZEfBvmvGMg6Y97kUewFyxBcTIy8QDI833P3l0MKy3q3xE1_tkY9JoCGfDvLIb0ULhWAPS-s9z2pDcGcO2WS-9Q6JrVg/https%3A%2F%2Fnam12.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Furld
> >
> efense.com%2Fv3%2F__https%3A%2F%2Fwww.businessinsider.com%2Fpau
> l-krugm
> > an-responds-to-internet-quote-2013-
> 12%3Famp__%3B!!JmPEgBY0HMszNaDT!pUV
> >
> U8USJPSqXuREx80y0bQ5MR7v2G271msUDJVyimwcA0x0oiPePyvVMbEFmX
> vp0KkVgyslQg
> >
> BkUcCIgOietLWEjpfoWVvXo%24=05%7C02%7CGIBNEY%40WSU.EDU%
> 7Ce292b02ec
> >
> ab547644c8d08dc34034e72%7Cb52be471f7f147b4a8790c799bb53db5%7
> C0%7C0%7C6
> >
> 38442436003405898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIjoi
> >
> V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=rkxa
> e42Xnjdr
> > ZsbYsztE%2FeQftM45pYXwoSisSXM3MvA%3D=0
> >
> >
> >
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Thursday, February 22, 2024, 5:12 PM, Bob Bridges <
> > 0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > Speaking of old predictions:  /* By 2005 or so, it will be clear that
> > the Internet's impact on the economy has been no greater than the fax
> > machine's.  -Paul Krugman, Nobel-prize-winning economist in 1998 */
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Lennie Dymoke-Bradshaw
> > Sent: Thursday, February 22, 2024 16:58
> >
> > Sorry, the date has been truncated on the left.
> > That should be 11994.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Allan Staller
> > Sent: 22 February 2024 19:42
> >
> > The last mainframe will be turned off in 1994 - Gartner Group
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Seymour J Metz
> > Sent: Thursday, February 22, 2024 11:11 AM
> >
> > A 5-year prediction is generally safe, because in 5 years people will
> > have forgotten the predictions. Who remembers the failed 5-year
> > predictions for, e.g., controlled fusion, human level machine translation?
> >
> > I expect it to eventually happen, but as for when, Hypotheses non
> > fingo <
> >
> https://secure-web.cisco.com/1CieSMPaZwvATHo3u6SeKwdTSLYWjrgzgHMj5G0cgeCU6OwRX-tYZ0dZywGFgIYxZ06npUpn5PdldAbPxondPyUXiudafJL2BDmpgDe6rIweSl28zsyyk2d3NIj-xPIx6hsP1J7Opb2qapLGK-iUSprkRmplH8sgKkH2Fa_GDPo3s5-6nMxBfty_xI1VeBOk3eZA2jCA0T-lEW75Uwsp9gT2BVKTGHZRysd2x6abN4KAFeZTovDz9zsB5F5HQrDt9snuZo7CYjPBb6oBbE3fHDt6B9Abfd4xRxhiXU5O_bnWnTmtJPekKqEj5EtxQBmN-0SFI7HoHDQAVGFH-ZEfBvmvGMg6Y97kUewFyxBcTIy8QDI833P3l0MKy3q3xE1_tkY9JoCGfDvLIb0ULhWAPS-s9z2pDcGcO2WS-9Q6JrVg/https%3A%2F%2Fnam12.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FHypo
> theses_non_fingo__%3B!!JmPEgBY0HMszNaDT!pUVU8USJPSqXuREx80y0bQ
> 5MR7v2G271msUDJVyimwcA0x0oiPePyvVMbEFmXvp0KkVgyslQgBkUcCIgOi
> etLWEjpRKs5ifv%24=05%7C02%7CGIBNEY%40WSU.EDU%7Ce292b02
> ecab547644c8d08dc34034e72%7Cb52be471f7f147b4a8790c799bb53db5
> %7C0%7C0%7C638442436003413344%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C0%7C%7C%7C=I69SwWniPcqnRRWi98MnELuNXk1a6kYh%2B1kY
> H9wRX2g%3D=0 >.
> >
> > On the flip side, hand optimization for pipelined machines is labor
> > intensive and fragile; a compiler with an ARCHLVL parameter is better
> > suited for the job.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access

Re: [Very much off-topic] Re: AI is the real deal.

2024-02-22 Thread Gibney, Dave

Fax machines are still heavily used un medical and legal areas

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of zMan
> Sent: Thursday, February 22, 2024 4:06 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [Very much off-topic] Re: AI is the real deal.
> 
> [EXTERNAL EMAIL]
> 
> The FAX machine's impact wasn't exactly tiny. Short-lived, yes.
> 
> On Thu, Feb 22, 2024 at 7:04 PM Dave Beagle < 0525eaef6620-dmarc-
> requ...@listserv.ua.edu> wrote:
> 
> > Picking on Krugman is typical of the right. But, that’s not exactly
> > what he said. Here’s the context.
> >
> >
> >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> >
> efense.com%2Fv3%2F__https%3A%2F%2Fwww.businessinsider.com%2Fpau
> l-krugm
> > an-responds-to-internet-quote-2013-
> 12%3Famp__%3B!!JmPEgBY0HMszNaDT!pUV
> >
> U8USJPSqXuREx80y0bQ5MR7v2G271msUDJVyimwcA0x0oiPePyvVMbEFmX
> vp0KkVgyslQg
> >
> BkUcCIgOietLWEjpfoWVvXo%24=05%7C02%7CGIBNEY%40WSU.EDU%
> 7Ce292b02ec
> >
> ab547644c8d08dc34034e72%7Cb52be471f7f147b4a8790c799bb53db5%7
> C0%7C0%7C6
> >
> 38442436003405898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIjoi
> >
> V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=rkxa
> e42Xnjdr
> > ZsbYsztE%2FeQftM45pYXwoSisSXM3MvA%3D=0
> >
> >
> >
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Thursday, February 22, 2024, 5:12 PM, Bob Bridges <
> > 0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > Speaking of old predictions:  /* By 2005 or so, it will be clear that
> > the Internet's impact on the economy has been no greater than the fax
> > machine's.  -Paul Krugman, Nobel-prize-winning economist in 1998 */
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Lennie Dymoke-Bradshaw
> > Sent: Thursday, February 22, 2024 16:58
> >
> > Sorry, the date has been truncated on the left.
> > That should be 11994.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Allan Staller
> > Sent: 22 February 2024 19:42
> >
> > The last mainframe will be turned off in 1994 - Gartner Group
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Seymour J Metz
> > Sent: Thursday, February 22, 2024 11:11 AM
> >
> > A 5-year prediction is generally safe, because in 5 years people will
> > have forgotten the predictions. Who remembers the failed 5-year
> > predictions for, e.g., controlled fusion, human level machine translation?
> >
> > I expect it to eventually happen, but as for when, Hypotheses non
> > fingo <
> >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FHypo
> theses_non_fingo__%3B!!JmPEgBY0HMszNaDT!pUVU8USJPSqXuREx80y0bQ
> 5MR7v2G271msUDJVyimwcA0x0oiPePyvVMbEFmXvp0KkVgyslQgBkUcCIgOi
> etLWEjpRKs5ifv%24=05%7C02%7CGIBNEY%40WSU.EDU%7Ce292b02
> ecab547644c8d08dc34034e72%7Cb52be471f7f147b4a8790c799bb53db5
> %7C0%7C0%7C638442436003413344%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C0%7C%7C%7C=I69SwWniPcqnRRWi98MnELuNXk1a6kYh%2B1kY
> H9wRX2g%3D=0 >.
> >
> > On the flip side, hand optimization for pipelined machines is labor
> > intensive and fragile; a compiler with an ARCHLVL parameter is better
> > suited for the job.
> >
> > --
> > 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
> >
> 
> 
> --
> zMan -- "I've got a mainframe and I'm not afraid to use it"
> 
> --
> 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: [Very much off-topic] Re: AI is the real deal.

2024-02-22 Thread zMan

The FAX machine's impact wasn't exactly tiny. Short-lived, yes.

On Thu, Feb 22, 2024 at 7:04 PM Dave Beagle <
0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:

> Picking on Krugman is typical of the right. But, that’s not exactly what
> he said. Here’s the context.
>
>
> https://www.businessinsider.com/paul-krugman-responds-to-internet-quote-2013-12?amp
>
>
>
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, February 22, 2024, 5:12 PM, Bob Bridges <
> 0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:
>
> Speaking of old predictions:  /* By 2005 or so, it will be clear that the
> Internet's impact on the economy has been no greater than the fax
> machine's.  -Paul Krugman, Nobel-prize-winning economist in 1998 */
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Lennie Dymoke-Bradshaw
> Sent: Thursday, February 22, 2024 16:58
>
> Sorry, the date has been truncated on the left.
> That should be 11994.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Allan Staller
> Sent: 22 February 2024 19:42
>
> The last mainframe will be turned off in 1994 - Gartner Group
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Seymour J Metz
> Sent: Thursday, February 22, 2024 11:11 AM
>
> A 5-year prediction is generally safe, because in 5 years people will have
> forgotten the predictions. Who remembers the failed 5-year predictions for,
> e.g., controlled fusion, human level machine translation?
>
> I expect it to eventually happen, but as for when, Hypotheses non fingo <
> https://en.wikipedia.org/wiki/Hypotheses_non_fingo>.
>
> On the flip side, hand optimization for pipelined machines is labor
> intensive and fragile; a compiler with an ARCHLVL parameter is better
> suited for the job.
>
> --
> 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
>


-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Very much off-topic] Re: AI is the real deal.

Picking on Krugman is typical of the right. But, that’s not exactly what he 
said. Here’s the context.

https://www.businessinsider.com/paul-krugman-responds-to-internet-quote-2013-12?amp





Sent from Yahoo Mail for iPhone


On Thursday, February 22, 2024, 5:12 PM, Bob Bridges 
<0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:

Speaking of old predictions:  /* By 2005 or so, it will be clear that the 
Internet's impact on the economy has been no greater than the fax machine's.  
-Paul Krugman, Nobel-prize-winning economist in 1998 */

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Dymoke-Bradshaw
Sent: Thursday, February 22, 2024 16:58

Sorry, the date has been truncated on the left. 
That should be 11994.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: 22 February 2024 19:42

The last mainframe will be turned off in 1994 - Gartner Group

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, February 22, 2024 11:11 AM

A 5-year prediction is generally safe, because in 5 years people will have 
forgotten the predictions. Who remembers the failed 5-year predictions for, 
e.g., controlled fusion, human level machine translation?

I expect it to eventually happen, but as for when, Hypotheses non fingo 
.

On the flip side, hand optimization for pipelined machines is labor intensive 
and fragile; a compiler with an ARCHLVL parameter is better suited for the job.

--
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: [Very much off-topic] Re: AI is the real deal.

2024-02-22 Thread zMan

> Current AI does not "understand" the information it holds, nor does
it have a concept of "truth".

So it's like a CEO. Good to know.

On Thu, Feb 22, 2024 at 6:13 PM Joel C. Ewing  wrote:

> One needs to understand that today's Large Language Model AI tools like
> ChatGPT, etc. are essentially driven by huge statistical databases
> created from processing huge volumes of digital text using some
> knowledge of sentence structure and words. Those tools can accept
> English-language queries and use words and phrases in the query to
> generate related-information responses with complete sentences and
> paragraphs that have a high probability of of being relevant to the query.
>
> Current AI does not "understand" the information it holds, nor does it
> have a concept of "truth".   Even if you program the AI using books on
> COBOL grammar and semantics it won't "understand" COBOL.   Even if you
> feed it millions of lines of COBOL code it won't be able to deduce the
> underlying purpose of the code.  If there is an accurate description of
> what the code does accompanying the code, it can associate that
> description with a code segment; but if the description is inaccurate,
> AI may also associate the code with that bad description.   Inevitably
> some of the code you might use to program the AI tool will contain bugs,
> and AI will be equally content to supply buggy code examples.
>
> If your object is to generate optimized Assembler code which accurately
> replicates the behavior of a COBOL program, the best tool for that for
> the foreseeable future is an optimizing COBOL compiler for your target
> machine.  Such compilers are already doing flow analysis just to
> optimize loops and register usage, but I wouldn't call that "AI" in the
> usual sense of that term. Perhaps a well-programmed AI tool would
> suggest using a COBOL compiler if asked to convert a COBOL program to
> assembler -- in fact that is basically the response given by the MS
> Copilot tool when asked to perform that task for z-architecture;
> although you can see hints of its lack of understanding in that in
> includes in its response "IBM provides cataloged procedures (such
> as*IEBCOMPR*and*IEBCOPY*) to simplify JCL coding for COBOL compilation",
> where it includes gratuitous PROC examples that have nothing to do with
> COBOL rather than giving the names of actual COBOL compiler PROCs.
>
>  Joel C. Ewing
>
> On 2/22/24 11:09, Robley Lutz wrote:
> > I guess my question is, do we expect AI to look at COBOL code, and not
> > simply compile it, but analyze the flow, and output optimized Assembler
> > code?  Will AI become the highly skilled Assembler programmer that I
> never
> > became?
> >
> > On Thu, Feb 22, 2024 at 11:54 AM Tom Harper <
> > 05bfa0e23abd-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >> Dave,
> >>
> >> I was told the same thing 54 years ago when I starting working at
> >> CalTrans. Managers would just be able to code in COBOL PROFITS = SALES -
> >> EXPENSES and we would all be out of a job.
> >>
> >> ...
>
> --
> Joel C. Ewing
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Very much off-topic] Re: AI is the real deal.

2024-02-22 Thread Joel C. Ewing

One needs to understand that today's Large Language Model AI tools like 
ChatGPT, etc. are essentially driven by huge statistical databases 
created from processing huge volumes of digital text using some 
knowledge of sentence structure and words. Those tools can accept 
English-language queries and use words and phrases in the query to 
generate related-information responses with complete sentences and 
paragraphs that have a high probability of of being relevant to the query.


Current AI does not "understand" the information it holds, nor does it 
have a concept of "truth".   Even if you program the AI using books on 
COBOL grammar and semantics it won't "understand" COBOL.   Even if you 
feed it millions of lines of COBOL code it won't be able to deduce the 
underlying purpose of the code.  If there is an accurate description of 
what the code does accompanying the code, it can associate that 
description with a code segment; but if the description is inaccurate, 
AI may also associate the code with that bad description.   Inevitably  
some of the code you might use to program the AI tool will contain bugs, 
and AI will be equally content to supply buggy code examples.


If your object is to generate optimized Assembler code which accurately 
replicates the behavior of a COBOL program, the best tool for that for 
the foreseeable future is an optimizing COBOL compiler for your target 
machine.  Such compilers are already doing flow analysis just to 
optimize loops and register usage, but I wouldn't call that "AI" in the 
usual sense of that term. Perhaps a well-programmed AI tool would 
suggest using a COBOL compiler if asked to convert a COBOL program to 
assembler -- in fact that is basically the response given by the MS 
Copilot tool when asked to perform that task for z-architecture; 
although you can see hints of its lack of understanding in that in 
includes in its response "IBM provides cataloged procedures (such 
as*IEBCOMPR*and*IEBCOPY*) to simplify JCL coding for COBOL compilation", 
where it includes gratuitous PROC examples that have nothing to do with 
COBOL rather than giving the names of actual COBOL compiler PROCs.


    Joel C. Ewing

On 2/22/24 11:09, Robley Lutz wrote:

I guess my question is, do we expect AI to look at COBOL code, and not
simply compile it, but analyze the flow, and output optimized Assembler
code?  Will AI become the highly skilled Assembler programmer that I never
became?

On Thu, Feb 22, 2024 at 11:54 AM Tom Harper <
05bfa0e23abd-dmarc-requ...@listserv.ua.edu> wrote:


Dave,

I was told the same thing 54 years ago when I starting working at
CalTrans. Managers would just be able to code in COBOL PROFITS = SALES -
EXPENSES and we would all be out of a job.

...


--
Joel C. Ewing

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Very much off-topic] Re: AI is the real deal.

2024-02-22 Thread Bob Bridges

Speaking of old predictions:  /* By 2005 or so, it will be clear that the 
Internet's impact on the economy has been no greater than the fax machine's.  
-Paul Krugman, Nobel-prize-winning economist in 1998 */

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Dymoke-Bradshaw
Sent: Thursday, February 22, 2024 16:58

Sorry, the date has been truncated on the left. 
That should be 11994.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: 22 February 2024 19:42

The last mainframe will be turned off in 1994 - Gartner Group

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, February 22, 2024 11:11 AM

A 5-year prediction is generally safe, because in 5 years people will have 
forgotten the predictions. Who remembers the failed 5-year predictions for, 
e.g., controlled fusion, human level machine translation?

I expect it to eventually happen, but as for when, Hypotheses non fingo 
.

On the flip side, hand optimization for pipelined machines is labor intensive 
and fragile; a compiler with an ARCHLVL parameter is better suited for the job.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Very much off-topic] Re: AI is the real deal.

2024-02-22 Thread Lennie Dymoke-Bradshaw

Sorry, the date has been truncated on the left. 
That should be 11994.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: 22 February 2024 19:42
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Very much off-topic] Re: AI is the real deal.

Classification: Confidential

The last mainframe will be turned off in 1994 - Gartner Group

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, February 22, 2024 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Very much off-topic] Re: AI is the real deal.

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

A 5-year prediction is generally safe, because in 5 years people will have 
forgotten the predictions. Who remembers the failed 5-year predictions for, 
e.g., controlled fusion, human level machine translation?

I expect it to eventually happen, but as for when, Hypotheses non fingo 
.

On the flip side, hand optimization for pipelined machines is labor intensive 
and fragile; a compiler with an ARCHLVL parameter is better suited for the job.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר

From: IBM Mainframe Discussion List  on behalf of Tom 
Harper <05bfa0e23abd-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, February 22, 2024 11:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Very much off-topic] Re: AI is the real deal.

Dave,

I was told the same thing 54 years ago when I starting working at CalTrans. 
Managers would just be able to code in COBOL PROFITS = SALES - EXPENSES and we 
would all be out of a job.

Of course, there are more programmers now  than at any time in history.

The question of assembler comes up from time to time, and the question has more 
nuances than you might think.

As it turns out, there are lines of code and lines of executed code. What that 
means is that lines of code that are executed frequently are seldom written in 
a compiled language but are instead written in assembler.

A good example is sort. In the 1970s sort typically used about a third of all 
processor and channel resources on a mainframe. Today that number is far lower, 
in the mid-teens despite the fact that much more data is being sorted.

The reason for this is that some very brilliant assembler programmers at 
SyncSort and the  IBM Dfsort team wrote code to highly optimize sorting and 
related functions. I’m counting PL/S as essentially assembler in this instance.

The same is true at BMC Software and my own company Phoenix Software 
International: highly optimized assembler code greatly improved performance.

Even though there are almost uncountable lines of COBOL code, it makes for a 
tiny fraction of executed code. Most compiled languages execute a few 
instructions and then invoke a CICS, IMS, or DB2 function.

Starting in the 1980s, corporations the world over began to understand that it 
was much more cost-effective to buy or lease software from a vendor than 
develop it in house. These developers left the end-user companies and went to 
software houses where they primarily write in assembler. Now ever piece of 
software usually has parts that are not performance-sensitive, so they might 
get written in C++ or Rex or some other compiled language.

I’ve grown up with software, having written my first program in 1960.

Assembler won’t be gone in five years or anytime can the foreseeable future.

So I would revisit your thoughts.

Tom Harper

Phoenix Software International

Sent from my iPhone

> On Feb 22, 2024, at 11:07 AM, Dave Beagle 
> <0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
>
> Assembler programming will be almost nonexistent in 5 years.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, February 22, 2024, 10:32 AM, Robert Prins 
> <05be6ef5bfea-dmarc-requ...@listserv.ua.edu> wrote:
>
> AI?
>
> More AS!
>
> This is on LinkedIn, it's AI generated and you can probably sue them 
> for jaw-dislocation due to excessive laughter:
>
> <
> https://www/.
> linkedin.com%2Fadvice%2F0%2Fhow-can-developers-take-ownership-bugs-ski
> lls-system-development-x9cve=05%7C02%7Callan.staller%40HCL.COM%7C
> cc68e10c66f6488fb04408dc33c94dc1%7C189de737c93a4f5a8b686f4ca9941912%7C
> 0%7C0%7C638442186902794249%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=3tT
> lvB8EH2KJyndo7QBf0U7KKjNBcexrXzghUxXy%2F5Q%3D=0
>>
>
>> On Wed, 21 Feb 2024 at 23:37, Dave Beagle < 
>> 0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
>>
>> Well, today was NVIDIA earnings day. They are the bellwether for AI.
>> Theirs is the premier AI chip commanding top dollar. And they didn’t 
>>

Re: Nanosecond resolution timestamps for HLL's?

D'oh. z/OS 2.4.

Oh well, won't waste anymore time on this now!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Sri 
Hari Kolusu
Sent: Thursday, February 22, 2024 2:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?

Michael,

What version of z/OS are you running ?  clock_gettime is available on z/OS V2R5 
and higher

Thanks,
Kolusu

--
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: Nanosecond resolution timestamps for HLL's?

2024-02-22 Thread Sri Hari Kolusu

Michael,

What version of z/OS are you running ?  clock_gettime is available on z/OS V2R5 
and higher 

Thanks,
Kolusu

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Nanosecond resolution timestamps for HLL's?

CEE.SCEELKEX isn't a PDSE. It is a DSORG=PS,RECFM=FB,LRECL=80 library 
containing 2,545 object decks (e.g. the .TXT records).

I'm having trouble finding definitive documentation, but from what I've found:

During final AUTOCALL processing, the binder reads the @@DC370$ member in 
SCEELKEX. That member is a directory of symbols to member names. If the symbol 
it wants is there, then it reads the member.

I don't see clock_gettime in the @@DC370$ member.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, February 22, 2024 1:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?

PDSE member names may be limited to 8 characters,  but alias names for a 
program object are not.

What are your Binder options?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Schmitt, Michael 
Sent: Thursday, February 22, 2024 9:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?

I'm testing using the standard IGYWCLG proc, which already has 
SYS1.CEE.SCEELKEX in the binder's SYSLIB. But I'm getting IEW2456E 9207 SYMBOL 
clock_gettime UNRESOLVED.  MEMBER COULD NOT BE INCLUDED FROM THE DESIGNATED 
CALL LIBRARY.

How would the bind work? The SCEELKEX library has 8 character member names. It 
seems like I'm missing a binder statement to direct it to the right member.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Wednesday, February 21, 2024 7:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?

No C compiler required.  The C runtime is required, but that comes with the OS 
(Language Environment).

You bind against SCEELKEX.  No Unix required.

From: IBM Mainframe Discussion List  on behalf of 
Schmitt, Michael 
Sent: Wednesday, February 21, 2024 4:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Nanosecond resolution timestamps for HLL's?

This requires a C compiler to be installed on z/OS, which doesn't come 
standard, correct?

And if you had z/OS XL C, how would you bind this? I mean, is this one of those 
things where you're binding against a path on the OEMVS side?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Tuesday, February 20, 2024 12:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?

Try this.


   process pgmname(longmixed) nodynam

   id division.

   program-id. 'cgettime_test'.

   data division.

   working-storage section.

   01  errno-ref   pointer.

   01  strerror-refpointer.

   01  len pic s9(9) comp-5.

   01  display-x.

   05  pic x occurs 0 to 1025 depending on len.



   01  clock_idpic s9(9) comp-5.

   01  timespec.

   05  secspic s9(9) comp-5.

   05  nsecs   pic s9(9) comp-5.

   01  rc  pic s9(9) comp-5.



   linkage section.

   01  errno   pic s9(9) comp-5.

   01  h_errno pic s9(9) comp-5.

   01  strerrorpic x(256).



   procedure division.

   call 'clock_gettime' using value clock_id

  reference timespec

returning rc

   if rc = zero

   display 'seconds: ' secs

   display 'nanoseconds:' nsecs

   else

   perform handle-error

   end-if

   goback.



   handle-error.

   call '__errno' returning errno-ref

   set address of errno to errno-ref

   call 'strerror' using value errno

returning strerror-ref

   set address of strerror to strerror-ref

   move 1025 to len

   unstring strerror delimited by x'00'

into display-x count len

   display quote display-x quote

   exit.



   end program 'cgettime_test'.




From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Monday, February 19, 2024 5:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Nanosecond resolution timestamps for HLL's?

My initial purpose is actually part of implementing COBOL-compatible min-heap 
priority queue functions that return equal-priority nodes in FIFO insert order 
when popped.  A timestamp or some other monotonically increasing integer 
tie-breaker provided with the input priority value is necessary to preserve 
FIFO order when pushing new items into the queue.  As Paul (gil) pointed out,

Re: [Very much off-topic] Re: AI is the real deal.

2024-02-22 Thread Allan Staller

Classification: Confidential

The last mainframe will be turned off in 1994 - Gartner Group

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, February 22, 2024 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Very much off-topic] Re: AI is the real deal.

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

A 5-year prediction is generally safe, because in 5 years people will have 
forgotten the predictions. Who remembers the failed 5-year predictions for, 
e.g., controlled fusion, human level machine translation?

I expect it to eventually happen, but as for when, Hypotheses non fingo 
.

On the flip side, hand optimization for pipelined machines is labor intensive 
and fragile; a compiler with an ARCHLVL parameter is better suited for the job.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר

From: IBM Mainframe Discussion List  on behalf of Tom 
Harper <05bfa0e23abd-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, February 22, 2024 11:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Very much off-topic] Re: AI is the real deal.

Dave,

I was told the same thing 54 years ago when I starting working at CalTrans. 
Managers would just be able to code in COBOL PROFITS = SALES - EXPENSES and we 
would all be out of a job.

Of course, there are more programmers now  than at any time in history.

The question of assembler comes up from time to time, and the question has more 
nuances than you might think.

As it turns out, there are lines of code and lines of executed code. What that 
means is that lines of code that are executed frequently are seldom written in 
a compiled language but are instead written in assembler.

A good example is sort. In the 1970s sort typically used about a third of all 
processor and channel resources on a mainframe. Today that number is far lower, 
in the mid-teens despite the fact that much more data is being sorted.

The reason for this is that some very brilliant assembler programmers at 
SyncSort and the  IBM Dfsort team wrote code to highly optimize sorting and 
related functions. I’m counting PL/S as essentially assembler in this instance.

The same is true at BMC Software and my own company Phoenix Software 
International: highly optimized assembler code greatly improved performance.

Even though there are almost uncountable lines of COBOL code, it makes for a 
tiny fraction of executed code. Most compiled languages execute a few 
instructions and then invoke a CICS, IMS, or DB2 function.

Starting in the 1980s, corporations the world over began to understand that it 
was much more cost-effective to buy or lease software from a vendor than 
develop it in house. These developers left the end-user companies and went to 
software houses where they primarily write in assembler. Now ever piece of 
software usually has parts that are not performance-sensitive, so they might 
get written in C++ or Rex or some other compiled language.

I’ve grown up with software, having written my first program in 1960.

Assembler won’t be gone in five years or anytime can the foreseeable future.

So I would revisit your thoughts.

Tom Harper

Phoenix Software International

Sent from my iPhone

> On Feb 22, 2024, at 11:07 AM, Dave Beagle 
> <0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
>
> Assembler programming will be almost nonexistent in 5 years.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, February 22, 2024, 10:32 AM, Robert Prins 
> <05be6ef5bfea-dmarc-requ...@listserv.ua.edu> wrote:
>
> AI?
>
> More AS!
>
> This is on LinkedIn, it's AI generated and you can probably sue them
> for jaw-dislocation due to excessive laughter:
>
> <
> https://www/.
> linkedin.com%2Fadvice%2F0%2Fhow-can-developers-take-ownership-bugs-ski
> lls-system-development-x9cve=05%7C02%7Callan.staller%40HCL.COM%7C
> cc68e10c66f6488fb04408dc33c94dc1%7C189de737c93a4f5a8b686f4ca9941912%7C
> 0%7C0%7C638442186902794249%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=3tT
> lvB8EH2KJyndo7QBf0U7KKjNBcexrXzghUxXy%2F5Q%3D=0
>>
>
>> On Wed, 21 Feb 2024 at 23:37, Dave Beagle <
>> 0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
>>
>> Well, today was NVIDIA earnings day. They are the bellwether for AI.
>> Theirs is the premier AI chip commanding top dollar. And they didn’t
>> disappoint. Their revenues are up 400% in the last year. To 22
>> billion in the latest quarter. They’ve got another chip on tap this
>> year which should continue the incredible growth. If you had invested
>> $10,000 five years ago, you’d have earned 2000%, and would have
>> $200,000. If you

Re: Nanosecond resolution timestamps for HLL's?

2024-02-22 Thread Colin Paice

The C header file has#pragma map(clock_gettime, "\174\174CGTIME")
which is @@CGTIME

My 64 bit binder has

* IMPORT CODE64,CELQV003,'clock_gettime',DADIMPORT
CODE64,CELQV003,'@@CGTIME',DAD  *
 IMPORT CODE64,CELQV003,'dup3',DAE
 IMPORT CODE64,CELQV003,'@@DUP3',DAE
Colin

On Thu, 22 Feb 2024 at 19:13, Seymour J Metz  wrote:

> PDSE member names may be limited to 8 characters,  but alias names for a
> program object are not.
>
> What are your Binder options?
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Schmitt, Michael 
> Sent: Thursday, February 22, 2024 9:59 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Nanosecond resolution timestamps for HLL's?
>
> I'm testing using the standard IGYWCLG proc, which already has
> SYS1.CEE.SCEELKEX in the binder's SYSLIB. But I'm getting IEW2456E 9207
> SYMBOL clock_gettime UNRESOLVED.  MEMBER COULD NOT BE INCLUDED FROM THE
> DESIGNATED CALL LIBRARY.
>
> How would the bind work? The SCEELKEX library has 8 character member
> names. It seems like I'm missing a binder statement to direct it to the
> right member.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Frank Swarbrick
> Sent: Wednesday, February 21, 2024 7:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Nanosecond resolution timestamps for HLL's?
>
> No C compiler required.  The C runtime is required, but that comes with
> the OS (Language Environment).
>
> You bind against SCEELKEX.  No Unix required.
> 
> From: IBM Mainframe Discussion List  on behalf
> of Schmitt, Michael 
> Sent: Wednesday, February 21, 2024 4:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Nanosecond resolution timestamps for HLL's?
>
> This requires a C compiler to be installed on z/OS, which doesn't come
> standard, correct?
>
> And if you had z/OS XL C, how would you bind this? I mean, is this one of
> those things where you're binding against a path on the OEMVS side?
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Frank Swarbrick
> Sent: Tuesday, February 20, 2024 12:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Nanosecond resolution timestamps for HLL's?
>
> Try this.
>
>
>process pgmname(longmixed) nodynam
>
>id division.
>
>program-id. 'cgettime_test'.
>
>data division.
>
>working-storage section.
>
>01  errno-ref   pointer.
>
>01  strerror-refpointer.
>
>01  len pic s9(9) comp-5.
>
>01  display-x.
>
>05  pic x occurs 0 to 1025 depending on len.
>
>
>
>01  clock_idpic s9(9) comp-5.
>
>01  timespec.
>
>05  secspic s9(9) comp-5.
>
>05  nsecs   pic s9(9) comp-5.
>
>01  rc  pic s9(9) comp-5.
>
>
>
>linkage section.
>
>01  errno   pic s9(9) comp-5.
>
>01  h_errno pic s9(9) comp-5.
>
>01  strerrorpic x(256).
>
>
>
>procedure division.
>
>call 'clock_gettime' using value clock_id
>
>   reference timespec
>
> returning rc
>
>if rc = zero
>
>display 'seconds: ' secs
>
>display 'nanoseconds:' nsecs
>
>else
>
>perform handle-error
>
>end-if
>
>goback.
>
>
>
>handle-error.
>
>call '__errno' returning errno-ref
>
>set address of errno to errno-ref
>
>call 'strerror' using value errno
>
> returning strerror-ref
>
>set address of strerror to strerror-ref
>
>move 1025 to len
>
>unstring strerror delimited by x'00'
>
> into display-x count len
>
>display quote display-x quote
>
>exit.
>
>
>
>end program 'cgettime_test'.
>
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
> Sent: Monday, February 19, 2024 5:30 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Nanosecond resolution timestamps for HLL's?
>
> My initial purpose is actually part of implementing COBOL-compatible
> min-heap priority queue functions that return equal-priority nodes in FIFO
> insert order when popped.  A timestamp or some other monotonically
> increasing integer tie-breaker provided with the input priority value is
> necessary to preserve FIFO order when pushing new items into the queue.  As
> Paul (gil) pointed out, named counters might provide a similar function but
> would be far more

Re: zsh for z/OS

The main benefit with zsh is compatibility with other platforms.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Pew, Curtis G 
Sent: Monday, February 19, 2024 2:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zsh for z/OS

On Feb 17, 2024, at 11:00 AM, Paul Gilmartin 
<042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

What are the benefits of zsh?  Are there incompatibilities?

I largely stay with POSIX shell for portability of scripts and skills.

Apple switched to zsh because newer versions of bash are covered by the GPLv3 
license, which is less corporate-friendly than the older GPLv2. I would assume 
that IBM has similar motivation.

If you’re still seeing bash on a Mac that probably means you started using it 
before the switch. It’s been a while, but when they switched the default I had 
to do something (probably in Terminal) to get it to switch for me. (It used to 
prompt you to switch if you opened with a bash shell.) There’s still bash 
available on MacOS, but it’s a rather old version, 3.2.57 while the current 
stable release is 5.2.21.


--
Curtis Pew
ITS Campus Solutions
curtis@austin.utexas.edu




--
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: Nanosecond resolution timestamps for HLL's?

PDSE member names may be limited to 8 characters,  but alias names for a 
program object are not.

What are your Binder options?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Schmitt, Michael 
Sent: Thursday, February 22, 2024 9:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?

I'm testing using the standard IGYWCLG proc, which already has 
SYS1.CEE.SCEELKEX in the binder's SYSLIB. But I'm getting IEW2456E 9207 SYMBOL 
clock_gettime UNRESOLVED.  MEMBER COULD NOT BE INCLUDED FROM THE DESIGNATED 
CALL LIBRARY.

How would the bind work? The SCEELKEX library has 8 character member names. It 
seems like I'm missing a binder statement to direct it to the right member.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Wednesday, February 21, 2024 7:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?

No C compiler required.  The C runtime is required, but that comes with the OS 
(Language Environment).

You bind against SCEELKEX.  No Unix required.

From: IBM Mainframe Discussion List  on behalf of 
Schmitt, Michael 
Sent: Wednesday, February 21, 2024 4:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Nanosecond resolution timestamps for HLL's?

This requires a C compiler to be installed on z/OS, which doesn't come 
standard, correct?

And if you had z/OS XL C, how would you bind this? I mean, is this one of those 
things where you're binding against a path on the OEMVS side?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Tuesday, February 20, 2024 12:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?

Try this.


   process pgmname(longmixed) nodynam

   id division.

   program-id. 'cgettime_test'.

   data division.

   working-storage section.

   01  errno-ref   pointer.

   01  strerror-refpointer.

   01  len pic s9(9) comp-5.

   01  display-x.

   05  pic x occurs 0 to 1025 depending on len.



   01  clock_idpic s9(9) comp-5.

   01  timespec.

   05  secspic s9(9) comp-5.

   05  nsecs   pic s9(9) comp-5.

   01  rc  pic s9(9) comp-5.



   linkage section.

   01  errno   pic s9(9) comp-5.

   01  h_errno pic s9(9) comp-5.

   01  strerrorpic x(256).



   procedure division.

   call 'clock_gettime' using value clock_id

  reference timespec

returning rc

   if rc = zero

   display 'seconds: ' secs

   display 'nanoseconds:' nsecs

   else

   perform handle-error

   end-if

   goback.



   handle-error.

   call '__errno' returning errno-ref

   set address of errno to errno-ref

   call 'strerror' using value errno

returning strerror-ref

   set address of strerror to strerror-ref

   move 1025 to len

   unstring strerror delimited by x'00'

into display-x count len

   display quote display-x quote

   exit.



   end program 'cgettime_test'.




From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Monday, February 19, 2024 5:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Nanosecond resolution timestamps for HLL's?

My initial purpose is actually part of implementing COBOL-compatible min-heap 
priority queue functions that return equal-priority nodes in FIFO insert order 
when popped.  A timestamp or some other monotonically increasing integer 
tie-breaker provided with the input priority value is necessary to preserve 
FIFO order when pushing new items into the queue.  As Paul (gil) pointed out, 
named counters might provide a similar function but would be far more 
performance-expensive compared to a simple STCK value.

Yes, I am aware that STCK breaks at the epoch in 2038 (or is it 2042? I forget 
now), which isn't ALL that far away.  A MetalC implementation for STCK values 
has been coded and works acceptably, as does of course a straight-forward 
assembler implementation.  Extension to use STCKE instead of STCK would be 
trivial in either case, but of course that also doubles the space occupied by 
the tiebreaker value.  I would much prefer an IBM-maintained solution that 
crosses the epoch barrier transparently.

A reasonably-well-performing implementation of

Recent CBTTape Updates

2024-02-22 Thread Lionel B. Dyck

Some recent updates to https://cbttape.org/updates.htm as reported using the
CBTView ISPF Dialog (found in file 043) sorted with the most current date on
top:

File  DescriptionDate  
135   Greg Price Load Module library   * 24/02/22  
182   PDS Command Package--Version 8.6.21.0-PDSE Support   * 24/02/22  
035   LOAD MODULE file - Quick install of useful programs  * 24/02/22  
492   SHOWzOS 8.02 and 7.25, plus SHOWMVS 7.10 and 6.30* 24/02/21  
614   SHOWMVS and SHOWzOS Load Libraries FB-80 XMIT format * 24/02/21  
435   Frank Clarke's execs having to do with TSO userids   * 24/02/14  
433   Frank Clarke's collection of REXX execs, etc.* 24/02/14  
997   ISPF Git Interface - ZIGI* 24/02/14  
1051  ZEMF Dynamic SMF Exits Alteration Facility - B.Marino* 24/02/14  
001   CBT DOC - Modified File 001 for Version 506  * 24/02/13  
043   The Official CBT Dialog for easy access to all files * 24/02/12  
648   ZRMS Resource Monitoring Subsystem from Ben Marino   * 24/02/11  
417   RACFADM - ISPF Dialog to make RACF admin easier. * 24/02/08  
314   Lionel Dyck Collection of Utilities. TX thru Z   * 24/02/01  
312   Lionel Dyck Collection of Utilities.  A thru R   * 24/01/30  
029   Cook Book instructions to Enlarge the VTOC of a pack * 24/01/24  
977   URL Table for MOSHIX YouTube Mainframe Videos* 24/01/24  

Just to highlight a few check out the enhanced PDS command (182), updated
SHOWZOS (614), How to enlarge a VTOC (029), User Friendly RACF Dialog (417),
and two new tools from Ben Marino (648 and 1051).

Lionel B. Dyck <>< 
#IBMChampion #OMPAmbassador 
Github: https://github.com/lbdyck
System Z Enthusiasts Discord:
https://discord.gg/system-z-enthusiasts-880322471608344597

Worry more about your character than your reputation. Character is what you
are, reputation merely what others think you are.   - - - John Wooden

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Very much off-topic] Re: AI is the real deal.

2024-02-22 Thread Steve Thompson

Right now there is a move within the US Fed Gov't to convert ALC
to Java.

They need ALC programmers that know the old style programming
because some of this code predates MVS/XA.

Just say'n'.

Steve Thompson

On 2/22/2024 12:29 PM, Dave Beagle wrote:

I don’t deny there will be assembler code running. It’s just that you won’t
need assembler programmers. It’s been shrinking for decades as a needed
skillset. Explains why hardly anyone teaches it and why assembler coding jobs
are few. Also explains why the Assembler listserv is almost dead. Ray Mullins,
many of whom would consider an expert agrees with me. Called it a niche skill.

To deny the fact that companies are spending large amounts of time and money on
AI is certainly a fools proposition. Literally, every IT company on the planet
is falling over themselves to get a piece of that pie. Those who aren’t are
going to have a hard time surviving. Even non IT companies can see a huge
benefit and payoff from it. This will be the most important IT venture to date.

People who want it to solve complex problems while AI is in its infancy, aren’t
thinking straight. AI is going to change everything in the next decade or so.
Anyone who is wondering what skills will be highly paid in the next 20 years,
I’ll guarantee AI will be near the top.

Plus, I’ve coded in numerous languages since 1980. Done just about everything
in IT. Was right about the mainframe being around for decades to come circa
1995 as many here kept saying the mainframe was dead.

Dave

Sent from Yahoo Mail for iPhone

On Thursday, February 22, 2024, 11:54 AM, Tom Harper
<05bfa0e23abd-dmarc-requ...@listserv.ua.edu> wrote:

Dave,

I was told the same thing 54 years ago when I starting working at CalTrans.
Managers would just be able to code in COBOL PROFITS = SALES - EXPENSES and we
would all be out of a job.

Of course, there are more programmers now than at any time in history.

The question of assembler comes up from time to time, and the question has more
nuances than you might think.

As it turns out, there are lines of code and lines of executed code. What that
means is that lines of code that are executed frequently are seldom written in
a compiled language but are instead written in assembler.

A good example is sort. In the 1970s sort typically used about a third of all
processor and channel resources on a mainframe. Today that number is far lower,
in the mid-teens despite the fact that much more data is being sorted.

The reason for this is that some very brilliant assembler programmers at
SyncSort and the IBM Dfsort team wrote code to highly optimize sorting and
related functions. I’m counting PL/S as essentially assembler in this instance.

The same is true at BMC Software and my own company Phoenix Software
International: highly optimized assembler code greatly improved performance.

Even though there are almost uncountable lines of COBOL code, it makes for a
tiny fraction of executed code. Most compiled languages execute a few
instructions and then invoke a CICS, IMS, or DB2 function.

Starting in the 1980s, corporations the world over began to understand that it
was much more cost-effective to buy or lease software from a vendor than
develop it in house. These developers left the end-user companies and went to
software houses where they primarily write in assembler. Now ever piece of
software usually has parts that are not performance-sensitive, so they might
get written in C++ or Rex or some other compiled language.

I’ve grown up with software, having written my first program in 1960.

Assembler won’t be gone in five years or anytime can the foreseeable future.

So I would revisit your thoughts.

Tom Harper

Phoenix Software International

Sent from my iPhone

On Feb 22, 2024, at 11:07 AM, Dave Beagle
<0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:

Assembler programming will be almost nonexistent in 5 years.

Sent from Yahoo Mail for iPhone

On Thursday, February 22, 2024, 10:32 AM, Robert Prins
<05be6ef5bfea-dmarc-requ...@listserv.ua.edu> wrote:

AI?

More AS!

This is on LinkedIn, it's AI generated and you can probably sue them for
jaw-dislocation due to excessive laughter:

<
https://www.linkedin.com/advice/0/how-can-developers-take-ownership-bugs-skills-system-development-x9cve

On Wed, 21 Feb 2024 at 23:37, Dave Beagle <
0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:

Well, today was NVIDIA earnings day. They are the bellwether for AI.
Theirs is the premier AI chip commanding top dollar. And they didn’t
disappoint. Their revenues are up 400% in the last year. To 22 billion in
the latest quarter. They’ve got another chip on tap this year which should
continue the incredible growth. If you had invested $10,000 five years ago,
you’d have earned 2000%, and would have $200,000. If you had
invested $10,000 ten years ago, you’d have earned over 16,465%. And have
1.65 million. AI is only in its infancy. It will

Re: [Very much off-topic] Re: AI is the real deal.

I don’t deny there will be assembler code running. It’s just that you won’t 
need assembler programmers. It’s been shrinking for decades as a needed 
skillset. Explains why hardly anyone teaches it and why assembler coding jobs 
are few. Also explains why the Assembler listserv is almost dead. Ray Mullins, 
many of whom would consider an expert agrees with me. Called it a niche skill.

To deny the fact that companies are spending large amounts of time and money on 
AI is certainly a fools proposition. Literally, every IT company on the planet 
is falling over themselves to get a piece of that pie. Those who aren’t are 
going to have a hard time surviving. Even non IT companies can see a huge 
benefit and payoff from it. This will be the most important IT venture to date.

People who want it to solve complex problems while AI is in its infancy, aren’t 
thinking straight. AI is going to change everything in the next decade or so. 
Anyone who is wondering what skills will be highly paid in the next 20 years, 
I’ll guarantee AI will be near the top.

Plus, I’ve coded in numerous languages since 1980. Done just about everything 
in IT. Was right about the mainframe being around for decades to come circa 
1995 as many here kept saying the mainframe was dead.

Dave

Sent from Yahoo Mail for iPhone

On Thursday, February 22, 2024, 11:54 AM, Tom Harper 
<05bfa0e23abd-dmarc-requ...@listserv.ua.edu> wrote:

Dave,

I was told the same thing 54 years ago when I starting working at CalTrans. 
Managers would just be able to code in COBOL PROFITS = SALES - EXPENSES and we 
would all be out of a job. 

Of course, there are more programmers now  than at any time in history. 

The question of assembler comes up from time to time, and the question has more 
nuances than you might think. 

As it turns out, there are lines of code and lines of executed code. What that 
means is that lines of code that are executed frequently are seldom written in 
a compiled language but are instead written in assembler.  

A good example is sort. In the 1970s sort typically used about a third of all 
processor and channel resources on a mainframe. Today that number is far lower, 
in the mid-teens despite the fact that much more data is being sorted. 

The reason for this is that some very brilliant assembler programmers at 
SyncSort and the  IBM Dfsort team wrote code to highly optimize sorting and 
related functions. I’m counting PL/S as essentially assembler in this instance. 

The same is true at BMC Software and my own company Phoenix Software 
International: highly optimized assembler code greatly improved performance. 

Even though there are almost uncountable lines of COBOL code, it makes for a 
tiny fraction of executed code. Most compiled languages execute a few 
instructions and then invoke a CICS, IMS, or DB2 function. 

Starting in the 1980s, corporations the world over began to understand that it 
was much more cost-effective to buy or lease software from a vendor than 
develop it in house. These developers left the end-user companies and went to 
software houses where they primarily write in assembler. Now ever piece of 
software usually has parts that are not performance-sensitive, so they might 
get written in C++ or Rex or some other compiled language. 

I’ve grown up with software, having written my first program in 1960. 

Assembler won’t be gone in five years or anytime can the foreseeable future. 

So I would revisit your thoughts.

Tom Harper 

Phoenix Software International 

Sent from my iPhone

> On Feb 22, 2024, at 11:07 AM, Dave Beagle 
> <0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Assembler programming will be almost nonexistent in 5 years.
> 
> 
> Sent from Yahoo Mail for iPhone
> 
> 
> On Thursday, February 22, 2024, 10:32 AM, Robert Prins 
> <05be6ef5bfea-dmarc-requ...@listserv.ua.edu> wrote:
> 
> AI?
> 
> More AS!
> 
> This is on LinkedIn, it's AI generated and you can probably sue them for
> jaw-dislocation due to excessive laughter:
> 
> <
> https://www.linkedin.com/advice/0/how-can-developers-take-ownership-bugs-skills-system-development-x9cve
>> 
> 
>> On Wed, 21 Feb 2024 at 23:37, Dave Beagle <
>> 0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> Well, today was NVIDIA earnings day. They are the bellwether for AI.
>> Theirs is the premier AI chip commanding top dollar. And they didn’t
>> disappoint. Their revenues are up 400% in the last year. To 22 billion in
>> the latest quarter. They’ve got another chip on tap this year which should
>> continue the incredible growth. If you had invested $10,000 five years ago,
>> you’d have earned 2000%, and would have $200,000. If you had
>> invested $10,000 ten years ago, you’d have earned over 16,465%. And have
>> 1.65 million. AI is only in its infancy. It will be bigger than the
>> internet. Microsoft, META, Google, and nearly every IT company is
>> betting big on AI. That spending will continue. NVIDIA’s market cap is
>>

Re: [Very much off-topic] Re: AI is the real deal.

"Ownership considered harmful:

Yes, you should accept responsibility for defects (not just bugs) in your work, 
but you should not consider it to be your turf and be hostile to those who 
improve it. If someone finds a bug in my code, i am and should be grateful. I 
might use a different fix from what they provided, but then again, I might not."

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Robert Prins <05be6ef5bfea-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, February 22, 2024 12:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [Very much off-topic] Re: AI is the real deal.

AI?

More AS!

This is on LinkedIn, it's AI generated and you can probably sue them for
jaw-dislocation due to excessive laughter:

<
https://www.linkedin.com/advice/0/how-can-developers-take-ownership-bugs-skills-system-development-x9cve
>

On Wed, 21 Feb 2024 at 23:37, Dave Beagle <
0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:

> Well, today was NVIDIA earnings day. They are the bellwether for AI.
> Theirs is the premier AI chip commanding top dollar. And they didn’t
> disappoint. Their revenues are up 400% in the last year. To 22 billion in
> the latest quarter. They’ve got another chip on tap this year which should
> continue the incredible growth. If you had invested $10,000 five years ago,
> you’d have earned 2000%, and would have $200,000. If you had
> invested $10,000 ten years ago, you’d have earned over 16,465%. And have
> 1.65 million. AI is only in its infancy. It will be bigger than the
> internet. Microsoft, META, Google, and nearly every IT company is
> betting big on AI. That spending will continue. NVIDIA’s market cap is
> approaching 2 trillion.  It’s now the 3rd largest company in the world by
> market cap. (Behind Microsoft & Apple) To think AI is just a passing fad is
> foolish.
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 

Some REXX code for use on z/OS


--
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: [Very much off-topic] Re: AI is the real deal.

2024-02-22 Thread Pommier, Rex

I can think of one guy who probably wishes a few more 5 year predictions would 
have been forgotten.  Stewart Alsop and his infamous 1991 prediction "I predict 
that the last mainframe will be unplugged on March 15, 1996".

oops

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, February 22, 2024 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: [Very much off-topic] Re: AI is the real deal.

A 5-year prediction is generally safe, because in 5 years people will have 
forgotten the predictions. Who remembers the failed 5-year predictions for, 
e.g., controlled fusion, human level machine translation?

I expect it to eventually happen, but as for when, Hypotheses non fingo 
.

On the flip side, hand optimization for pipelined machines is labor intensive 
and fragile; a compiler with an ARCHLVL parameter is better suited for the job.

--
Shmuel (Seymour J.) Metz
https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!KjMRP1Ixj6eLE0Fj!sFC-mjDAKaitFM9IEYw4ZOP8uKU9vq50VIYYHq7QWJoDB9QKgOmsB_xLkcXGfUXtjbbOfYuQldUa1eC9wA$
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר

From: IBM Mainframe Discussion List  on behalf of Tom 
Harper <05bfa0e23abd-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, February 22, 2024 11:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Very much off-topic] Re: AI is the real deal.

Dave,

I was told the same thing 54 years ago when I starting working at CalTrans. 
Managers would just be able to code in COBOL PROFITS = SALES - EXPENSES and we 
would all be out of a job.

Of course, there are more programmers now  than at any time in history.

The question of assembler comes up from time to time, and the question has more 
nuances than you might think.

As it turns out, there are lines of code and lines of executed code. What that 
means is that lines of code that are executed frequently are seldom written in 
a compiled language but are instead written in assembler.

A good example is sort. In the 1970s sort typically used about a third of all 
processor and channel resources on a mainframe. Today that number is far lower, 
in the mid-teens despite the fact that much more data is being sorted.

The reason for this is that some very brilliant assembler programmers at 
SyncSort and the  IBM Dfsort team wrote code to highly optimize sorting and 
related functions. I’m counting PL/S as essentially assembler in this instance.

The same is true at BMC Software and my own company Phoenix Software 
International: highly optimized assembler code greatly improved performance.

Even though there are almost uncountable lines of COBOL code, it makes for a 
tiny fraction of executed code. Most compiled languages execute a few 
instructions and then invoke a CICS, IMS, or DB2 function.

Starting in the 1980s, corporations the world over began to understand that it 
was much more cost-effective to buy or lease software from a vendor than 
develop it in house. These developers left the end-user companies and went to 
software houses where they primarily write in assembler. Now ever piece of 
software usually has parts that are not performance-sensitive, so they might 
get written in C++ or Rex or some other compiled language.

I’ve grown up with software, having written my first program in 1960.

Assembler won’t be gone in five years or anytime can the foreseeable future.

So I would revisit your thoughts.

Tom Harper

Phoenix Software International

Sent from my iPhone

> On Feb 22, 2024, at 11:07 AM, Dave Beagle 
> <0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
>
> Assembler programming will be almost nonexistent in 5 years.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, February 22, 2024, 10:32 AM, Robert Prins 
> <05be6ef5bfea-dmarc-requ...@listserv.ua.edu> wrote:
>
> AI?
>
> More AS!
>
> This is on LinkedIn, it's AI generated and you can probably sue them 
> for jaw-dislocation due to excessive laughter:
>
> <
> https://urldefense.com/v3/__https://www.linkedin.com/advice/0/how-can-
> developers-take-ownership-bugs-skills-system-development-x9cve__;!!KjM
> RP1Ixj6eLE0Fj!sFC-mjDAKaitFM9IEYw4ZOP8uKU9vq50VIYYHq7QWJoDB9QKgOmsB_xL
> kcXGfUXtjbbOfYuQldVStGcE7g$
>>
>
>> On Wed, 21 Feb 2024 at 23:37, Dave Beagle < 
>> 0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
>>
>> Well, today was NVIDIA earnings day. They are the bellwether for AI.
>> Theirs is the premier AI chip commanding top dollar. And they didn’t 
>> disappoint. Their revenues are up 400% in the last year. To 22 
>> billion in the latest quarter. They’ve got another chip on tap this 
>> year which should continue the incredible growth. If you had invested 
>> $10,000 five years ago, you’d have earned

Re: [Very much off-topic] Re: AI is the real deal.

No, but we might see AI look at problem specifications and generate machine 
code that is hard to express in COBOL.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Robley Lutz <05c088572ccb-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, February 22, 2024 12:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Very much off-topic] Re: AI is the real deal.

I guess my question is, do we expect AI to look at COBOL code, and not
simply compile it, but analyze the flow, and output optimized Assembler
code?  Will AI become the highly skilled Assembler programmer that I never
became?

On Thu, Feb 22, 2024 at 11:54 AM Tom Harper <
05bfa0e23abd-dmarc-requ...@listserv.ua.edu> wrote:

> Dave,
>
> I was told the same thing 54 years ago when I starting working at
> CalTrans. Managers would just be able to code in COBOL PROFITS = SALES -
> EXPENSES and we would all be out of a job.
>
> Of course, there are more programmers now  than at any time in history.
>
> The question of assembler comes up from time to time, and the question has
> more nuances than you might think.
>
> As it turns out, there are lines of code and lines of executed code. What
> that means is that lines of code that are executed frequently are seldom
> written in a compiled language but are instead written in assembler.
>
> A good example is sort. In the 1970s sort typically used about a third of
> all processor and channel resources on a mainframe. Today that number is
> far lower, in the mid-teens despite the fact that much more data is being
> sorted.
>
> The reason for this is that some very brilliant assembler programmers at
> SyncSort and the  IBM Dfsort team wrote code to highly optimize sorting and
> related functions. I’m counting PL/S as essentially assembler in this
> instance.
>
> The same is true at BMC Software and my own company Phoenix Software
> International: highly optimized assembler code greatly improved
> performance.
>
> Even though there are almost uncountable lines of COBOL code, it makes for
> a tiny fraction of executed code. Most compiled languages execute a few
> instructions and then invoke a CICS, IMS, or DB2 function.
>
> Starting in the 1980s, corporations the world over began to understand
> that it was much more cost-effective to buy or lease software from a vendor
> than develop it in house. These developers left the end-user companies and
> went to software houses where they primarily write in assembler. Now ever
> piece of software usually has parts that are not performance-sensitive, so
> they might get written in C++ or Rex or some other compiled language.
>
> I’ve grown up with software, having written my first program in 1960.
>
> Assembler won’t be gone in five years or anytime can the foreseeable
> future.
>
> So I would revisit your thoughts.
>
> Tom Harper
>
> Phoenix Software International
>
> Sent from my iPhone
>
> > On Feb 22, 2024, at 11:07 AM, Dave Beagle <
> 0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > Assembler programming will be almost nonexistent in 5 years.
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Thursday, February 22, 2024, 10:32 AM, Robert Prins <
> 05be6ef5bfea-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > AI?
> >
> > More AS!
> >
> > This is on LinkedIn, it's AI generated and you can probably sue them for
> > jaw-dislocation due to excessive laughter:
> >
> > <
> >
> https://www.linkedin.com/advice/0/how-can-developers-take-ownership-bugs-skills-system-development-x9cve
> >>
> >
> >> On Wed, 21 Feb 2024 at 23:37, Dave Beagle <
> >> 0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
> >>
> >> Well, today was NVIDIA earnings day. They are the bellwether for AI.
> >> Theirs is the premier AI chip commanding top dollar. And they didn’t
> >> disappoint. Their revenues are up 400% in the last year. To 22 billion
> in
> >> the latest quarter. They’ve got another chip on tap this year which
> should
> >> continue the incredible growth. If you had invested $10,000 five years
> ago,
> >> you’d have earned 2000%, and would have $200,000. If you had
> >> invested $10,000 ten years ago, you’d have earned over 16,465%. And have
> >> 1.65 million. AI is only in its infancy. It will be bigger than the
> >> internet. Microsoft, META, Google, and nearly every IT company is
> >> betting big on AI. That spending will continue. NVIDIA’s market cap is
> >> approaching 2 trillion.  It’s now the 3rd largest company in
>
>
>
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review,

Re: [Very much off-topic] Re: AI is the real deal.

A 5-year prediction is generally safe, because in 5 years people will have 
forgotten the predictions. Who remembers the failed 5-year predictions for, 
e.g., controlled fusion, human level machine translation?

I expect it to eventually happen, but as for when, Hypotheses non fingo 
.

On the flip side, hand optimization for pipelined machines is labor intensive 
and fragile; a compiler with an ARCHLVL parameter is better suited for the job.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר

From: IBM Mainframe Discussion List  on behalf of Tom 
Harper <05bfa0e23abd-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, February 22, 2024 11:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Very much off-topic] Re: AI is the real deal.

Dave,

I was told the same thing 54 years ago when I starting working at CalTrans. 
Managers would just be able to code in COBOL PROFITS = SALES - EXPENSES and we 
would all be out of a job.

Of course, there are more programmers now  than at any time in history.

The question of assembler comes up from time to time, and the question has more 
nuances than you might think.

As it turns out, there are lines of code and lines of executed code. What that 
means is that lines of code that are executed frequently are seldom written in 
a compiled language but are instead written in assembler.

A good example is sort. In the 1970s sort typically used about a third of all 
processor and channel resources on a mainframe. Today that number is far lower, 
in the mid-teens despite the fact that much more data is being sorted.

The reason for this is that some very brilliant assembler programmers at 
SyncSort and the  IBM Dfsort team wrote code to highly optimize sorting and 
related functions. I’m counting PL/S as essentially assembler in this instance.

The same is true at BMC Software and my own company Phoenix Software 
International: highly optimized assembler code greatly improved performance.

Even though there are almost uncountable lines of COBOL code, it makes for a 
tiny fraction of executed code. Most compiled languages execute a few 
instructions and then invoke a CICS, IMS, or DB2 function.

Starting in the 1980s, corporations the world over began to understand that it 
was much more cost-effective to buy or lease software from a vendor than 
develop it in house. These developers left the end-user companies and went to 
software houses where they primarily write in assembler. Now ever piece of 
software usually has parts that are not performance-sensitive, so they might 
get written in C++ or Rex or some other compiled language.

I’ve grown up with software, having written my first program in 1960.

Assembler won’t be gone in five years or anytime can the foreseeable future.

So I would revisit your thoughts.

Tom Harper

Phoenix Software International

Sent from my iPhone

> On Feb 22, 2024, at 11:07 AM, Dave Beagle 
> <0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
>
> Assembler programming will be almost nonexistent in 5 years.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, February 22, 2024, 10:32 AM, Robert Prins 
> <05be6ef5bfea-dmarc-requ...@listserv.ua.edu> wrote:
>
> AI?
>
> More AS!
>
> This is on LinkedIn, it's AI generated and you can probably sue them for
> jaw-dislocation due to excessive laughter:
>
> <
> https://www.linkedin.com/advice/0/how-can-developers-take-ownership-bugs-skills-system-development-x9cve
>>
>
>> On Wed, 21 Feb 2024 at 23:37, Dave Beagle <
>> 0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
>>
>> Well, today was NVIDIA earnings day. They are the bellwether for AI.
>> Theirs is the premier AI chip commanding top dollar. And they didn’t
>> disappoint. Their revenues are up 400% in the last year. To 22 billion in
>> the latest quarter. They’ve got another chip on tap this year which should
>> continue the incredible growth. If you had invested $10,000 five years ago,
>> you’d have earned 2000%, and would have $200,000. If you had
>> invested $10,000 ten years ago, you’d have earned over 16,465%. And have
>> 1.65 million. AI is only in its infancy. It will be bigger than the
>> internet. Microsoft, META, Google, and nearly every IT company is
>> betting big on AI. That spending will continue. NVIDIA’s market cap is
>> approaching 2 trillion.  It’s now the 3rd largest company in

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not

Re: [Very much off-topic] Re: AI is the real deal.

2024-02-22 Thread Robley Lutz

I guess my question is, do we expect AI to look at COBOL code, and not
simply compile it, but analyze the flow, and output optimized Assembler
code?  Will AI become the highly skilled Assembler programmer that I never
became?

On Thu, Feb 22, 2024 at 11:54 AM Tom Harper <
05bfa0e23abd-dmarc-requ...@listserv.ua.edu> wrote:

> Dave,
>
> I was told the same thing 54 years ago when I starting working at
> CalTrans. Managers would just be able to code in COBOL PROFITS = SALES -
> EXPENSES and we would all be out of a job.
>
> Of course, there are more programmers now  than at any time in history.
>
> The question of assembler comes up from time to time, and the question has
> more nuances than you might think.
>
> As it turns out, there are lines of code and lines of executed code. What
> that means is that lines of code that are executed frequently are seldom
> written in a compiled language but are instead written in assembler.
>
> A good example is sort. In the 1970s sort typically used about a third of
> all processor and channel resources on a mainframe. Today that number is
> far lower, in the mid-teens despite the fact that much more data is being
> sorted.
>
> The reason for this is that some very brilliant assembler programmers at
> SyncSort and the  IBM Dfsort team wrote code to highly optimize sorting and
> related functions. I’m counting PL/S as essentially assembler in this
> instance.
>
> The same is true at BMC Software and my own company Phoenix Software
> International: highly optimized assembler code greatly improved
> performance.
>
> Even though there are almost uncountable lines of COBOL code, it makes for
> a tiny fraction of executed code. Most compiled languages execute a few
> instructions and then invoke a CICS, IMS, or DB2 function.
>
> Starting in the 1980s, corporations the world over began to understand
> that it was much more cost-effective to buy or lease software from a vendor
> than develop it in house. These developers left the end-user companies and
> went to software houses where they primarily write in assembler. Now ever
> piece of software usually has parts that are not performance-sensitive, so
> they might get written in C++ or Rex or some other compiled language.
>
> I’ve grown up with software, having written my first program in 1960.
>
> Assembler won’t be gone in five years or anytime can the foreseeable
> future.
>
> So I would revisit your thoughts.
>
> Tom Harper
>
> Phoenix Software International
>
> Sent from my iPhone
>
> > On Feb 22, 2024, at 11:07 AM, Dave Beagle <
> 0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > Assembler programming will be almost nonexistent in 5 years.
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Thursday, February 22, 2024, 10:32 AM, Robert Prins <
> 05be6ef5bfea-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > AI?
> >
> > More AS!
> >
> > This is on LinkedIn, it's AI generated and you can probably sue them for
> > jaw-dislocation due to excessive laughter:
> >
> > <
> >
> https://www.linkedin.com/advice/0/how-can-developers-take-ownership-bugs-skills-system-development-x9cve
> >>
> >
> >> On Wed, 21 Feb 2024 at 23:37, Dave Beagle <
> >> 0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
> >>
> >> Well, today was NVIDIA earnings day. They are the bellwether for AI.
> >> Theirs is the premier AI chip commanding top dollar. And they didn’t
> >> disappoint. Their revenues are up 400% in the last year. To 22 billion
> in
> >> the latest quarter. They’ve got another chip on tap this year which
> should
> >> continue the incredible growth. If you had invested $10,000 five years
> ago,
> >> you’d have earned 2000%, and would have $200,000. If you had
> >> invested $10,000 ten years ago, you’d have earned over 16,465%. And have
> >> 1.65 million. AI is only in its infancy. It will be bigger than the
> >> internet. Microsoft, META, Google, and nearly every IT company is
> >> betting big on AI. That spending will continue. NVIDIA’s market cap is
> >> approaching 2 trillion.  It’s now the 3rd largest company in
>
>
>
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although this
> email message and any attachments or appended messages are believed to be
> free of any virus or other defect that might affect any computer system
> into
>

Re: [Very much off-topic] Re: AI is the real deal.

2024-02-22 Thread Tom Harper

Dave,

I was told the same thing 54 years ago when I starting working at CalTrans. 
Managers would just be able to code in COBOL PROFITS = SALES - EXPENSES and we 
would all be out of a job. 

Of course, there are more programmers now  than at any time in history. 

The question of assembler comes up from time to time, and the question has more 
nuances than you might think. 

As it turns out, there are lines of code and lines of executed code. What that 
means is that lines of code that are executed frequently are seldom written in 
a compiled language but are instead written in assembler.  

A good example is sort. In the 1970s sort typically used about a third of all 
processor and channel resources on a mainframe. Today that number is far lower, 
in the mid-teens despite the fact that much more data is being sorted. 

The reason for this is that some very brilliant assembler programmers at 
SyncSort and the  IBM Dfsort team wrote code to highly optimize sorting and 
related functions. I’m counting PL/S as essentially assembler in this instance. 

The same is true at BMC Software and my own company Phoenix Software 
International: highly optimized assembler code greatly improved performance. 

Even though there are almost uncountable lines of COBOL code, it makes for a 
tiny fraction of executed code. Most compiled languages execute a few 
instructions and then invoke a CICS, IMS, or DB2 function. 

Starting in the 1980s, corporations the world over began to understand that it 
was much more cost-effective to buy or lease software from a vendor than 
develop it in house. These developers left the end-user companies and went to 
software houses where they primarily write in assembler. Now ever piece of 
software usually has parts that are not performance-sensitive, so they might 
get written in C++ or Rex or some other compiled language. 

I’ve grown up with software, having written my first program in 1960. 

Assembler won’t be gone in five years or anytime can the foreseeable future. 

So I would revisit your thoughts.

Tom Harper 

Phoenix Software International 

Sent from my iPhone

> On Feb 22, 2024, at 11:07 AM, Dave Beagle 
> <0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Assembler programming will be almost nonexistent in 5 years.
> 
> 
> Sent from Yahoo Mail for iPhone
> 
> 
> On Thursday, February 22, 2024, 10:32 AM, Robert Prins 
> <05be6ef5bfea-dmarc-requ...@listserv.ua.edu> wrote:
> 
> AI?
> 
> More AS!
> 
> This is on LinkedIn, it's AI generated and you can probably sue them for
> jaw-dislocation due to excessive laughter:
> 
> <
> https://www.linkedin.com/advice/0/how-can-developers-take-ownership-bugs-skills-system-development-x9cve
>> 
> 
>> On Wed, 21 Feb 2024 at 23:37, Dave Beagle <
>> 0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> Well, today was NVIDIA earnings day. They are the bellwether for AI.
>> Theirs is the premier AI chip commanding top dollar. And they didn’t
>> disappoint. Their revenues are up 400% in the last year. To 22 billion in
>> the latest quarter. They’ve got another chip on tap this year which should
>> continue the incredible growth. If you had invested $10,000 five years ago,
>> you’d have earned 2000%, and would have $200,000. If you had
>> invested $10,000 ten years ago, you’d have earned over 16,465%. And have
>> 1.65 million. AI is only in its infancy. It will be bigger than the
>> internet. Microsoft, META, Google, and nearly every IT company is
>> betting big on AI. That spending will continue. NVIDIA’s market cap is
>> approaching 2 trillion.  It’s now the 3rd largest company in

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [Very much off-topic] Re: AI is the real deal.

On LinkedIn I searched for AI jobs and got 154,000 hits. I then searched for 
Assembler jobs and got 6478 hits. As a very smart person said, AI won’t replace 
workers, people who know AI will replace people who don’t.


Sent from Yahoo Mail for iPhone


On Thursday, February 22, 2024, 11:08 AM, Dave Beagle 
<0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:

Assembler programming will be almost nonexistent in 5 years.


Sent from Yahoo Mail for iPhone


On Thursday, February 22, 2024, 10:32 AM, Robert Prins 
<05be6ef5bfea-dmarc-requ...@listserv.ua.edu> wrote:

AI?

More AS!

This is on LinkedIn, it's AI generated and you can probably sue them for
jaw-dislocation due to excessive laughter:

<
https://www.linkedin.com/advice/0/how-can-developers-take-ownership-bugs-skills-system-development-x9cve
>

On Wed, 21 Feb 2024 at 23:37, Dave Beagle <
0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:

> Well, today was NVIDIA earnings day. They are the bellwether for AI.
> Theirs is the premier AI chip commanding top dollar. And they didn’t
> disappoint. Their revenues are up 400% in the last year. To 22 billion in
> the latest quarter. They’ve got another chip on tap this year which should
> continue the incredible growth. If you had invested $10,000 five years ago,
> you’d have earned 2000%, and would have $200,000. If you had
> invested $10,000 ten years ago, you’d have earned over 16,465%. And have
> 1.65 million. AI is only in its infancy. It will be bigger than the
> internet. Microsoft, META, Google, and nearly every IT company is
> betting big on AI. That spending will continue. NVIDIA’s market cap is
> approaching 2 trillion.  It’s now the 3rd largest company in the world by
> market cap. (Behind Microsoft & Apple) To think AI is just a passing fad is
> foolish.
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


--
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: [Very much off-topic] Re: AI is the real deal.

Assembler programming will be almost nonexistent in 5 years.


Sent from Yahoo Mail for iPhone


On Thursday, February 22, 2024, 10:32 AM, Robert Prins 
<05be6ef5bfea-dmarc-requ...@listserv.ua.edu> wrote:

AI?

More AS!

This is on LinkedIn, it's AI generated and you can probably sue them for
jaw-dislocation due to excessive laughter:

<
https://www.linkedin.com/advice/0/how-can-developers-take-ownership-bugs-skills-system-development-x9cve
>

On Wed, 21 Feb 2024 at 23:37, Dave Beagle <
0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:

> Well, today was NVIDIA earnings day. They are the bellwether for AI.
> Theirs is the premier AI chip commanding top dollar. And they didn’t
> disappoint. Their revenues are up 400% in the last year. To 22 billion in
> the latest quarter. They’ve got another chip on tap this year which should
> continue the incredible growth. If you had invested $10,000 five years ago,
> you’d have earned 2000%, and would have $200,000. If you had
> invested $10,000 ten years ago, you’d have earned over 16,465%. And have
> 1.65 million. AI is only in its infancy. It will be bigger than the
> internet. Microsoft, META, Google, and nearly every IT company is
> betting big on AI. That spending will continue. NVIDIA’s market cap is
> approaching 2 trillion.  It’s now the 3rd largest company in the world by
> market cap. (Behind Microsoft & Apple) To think AI is just a passing fad is
> foolish.
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


--
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

COBOL 6 and On Size Error at ARCH(12)

I'm in discussion with IBM on a issue with the COBOL 6 compiler at ARCH level 
12. I think it is generating incorrect code, Development says "but generating 
correct code would make it less faster!". I want to see what you think.

The issue is related to overflows, such as a packed-decimal overflow. COBOL 
/ignores/ overflows, unless you code ON SIZE ERROR, which catches them. By 
"ignores" I mean it just lets the field overflow.

But at the machine level, a doing an AP instruction that causes an overflow (or 
any other instruction) will case a program check, depending on the setting of 
the decimal-overflow mask in the PSW. Therefore Language Environments sets the 
bit off to ignore overflows.

BUT, C semantics are that it needs to actually raise an exception or something 
when there is an overflow. When a COBOL program calls a C program, LE sets the 
overflow bit on so now overflows actually get a program check (which may be 
caught by an ESPIE). Upon return from C, LE doesn't set the bit back to off. 
Instead, LE catches the overflows and ignores them.

Note that this isn't just an application COBOL program calling an application C 
program. It also include use of services written in C. For example, the mere 
inclusion of XML PARSE or XML GENERATE in a COBOL program will drive LE to 
initialize the C interface, setting the overflow mask on.

That's how it is supposed to work.

But, sometimes after LE changes the bit to on, LE loses its conditional 
handlers. The result is that a COBOL program *will* get a program check for an 
overflow. How can this happen, you ask? One way involves reusable run-time 
systems established by CEEPIPI. (I have an Idea open about this issue.)

The work around for that problem is that if you code ON SIZE ERROR, COBOL will 
catch the overflow. I say this means "catch the overflow WITHOUT A PROGRAM 
CHECK", Development says "show us the doco that says it must catch it!".

Anyway, at arch levels 11 lower, a COBOL program will not get a program check 
when there is an overflow in a statement that has ON SIZE ERROR. The *way* it 
prevents this is it generates code that performs the operation using fields 
that are large enough that no overflow can occur, then it tests to see if it 
overflowed into the larger field. For example, if you are adding a 1 digit 
field to a 3 digit field, then the COBOL compiler does the add using a 4 digit 
field, and then checks if the high digit is not 0. If it is, then it goes into 
the ON SIZE ERROR logic. So, no program check, because at a machine level there 
was no overflow.

The difference with arch level 12 is that the IBM Enterprise COBOL for z/OS v6 
compiler will exploit the vector decimal instructions. These instructions have 
PSW bits that control whether they will fire a program-check for overflows.

And that's where we hit the issue. If we're in the situation where COBOL is 
using C (such as, XML PARSE or GENERATE), so LE has changed the PSW to no 
longer ignore the overflows, and LE has lost its condition handler, and the 
COBOL code has an overflow, and ON SIZE ERROR was coded, you still get a 
program check. For example, a S0CA in a VAP or VPS instruction. But unlike arch 
11 and below, there's no work-around.

Development doesn't want to add the "use larger fields" logic to the generated 
vector instructions, like they do for the non-vector generated code, because if 
they did, the generated vector code wouldn't be as fast as the code that is 
generated that allows the program check with ON SIZE ERROR.

I say, "but COBOL semantics require code in ON SIZE ERROR to not overflow". 
They say I need to prove that.

There solution is to a) don't use arch(12), or b) make your fields larger so 
they don't overflow, or c) add logic around every possible overflow that calls 
an assembler program to save and restore the overflow mask bits.

What do you think? Am I crazy to think that the compiler should generate the 
vector decimal instructions to not do a program check when ON SIZE ERROR is 
coded?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

[Very much off-topic] Re: AI is the real deal.

2024-02-22 Thread Robert Prins

AI?

More AS!

This is on LinkedIn, it's AI generated and you can probably sue them for
jaw-dislocation due to excessive laughter:

<
https://www.linkedin.com/advice/0/how-can-developers-take-ownership-bugs-skills-system-development-x9cve
>

On Wed, 21 Feb 2024 at 23:37, Dave Beagle <
0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:

> Well, today was NVIDIA earnings day. They are the bellwether for AI.
> Theirs is the premier AI chip commanding top dollar. And they didn’t
> disappoint. Their revenues are up 400% in the last year. To 22 billion in
> the latest quarter. They’ve got another chip on tap this year which should
> continue the incredible growth. If you had invested $10,000 five years ago,
> you’d have earned 2000%, and would have $200,000. If you had
> invested $10,000 ten years ago, you’d have earned over 16,465%. And have
> 1.65 million. AI is only in its infancy. It will be bigger than the
> internet. Microsoft, META, Google, and nearly every IT company is
> betting big on AI. That spending will continue. NVIDIA’s market cap is
> approaching 2 trillion.  It’s now the 3rd largest company in the world by
> market cap. (Behind Microsoft & Apple) To think AI is just a passing fad is
> foolish.
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Nanosecond resolution timestamps for HLL's?