date:20230302

On 3/3/23 12:51, Mike Schwab wrote:

They only got a few dongles out before they shut the program down.

That's disappointing. IIRC, IBM allow access to containerized z/OS
images. I don't know anything about how one would procure access but I
believe Peter Farley has experience in that space.

On Thu, Mar 2, 2023 at 10:22 PM David Crayford wrote:

It's my understanding that IBM made the zPDT available at a much more
affordable price with quite restrictive T's. I do agree with your
sentiments. I work with young guys and they raised the same point,
accessibility to a system to kick tires is an issue for young guys
considering a career as a mainframer.

On 3/3/23 11:27, David Spiegel wrote:

Hi David,
You said: "... If we want to attract and retain young talent we need
tools that they are familiar with ...".
That is not the entire story. IBM also should realize that allowing
people to experiment with z/OS via Hercules (for free) is in their
best interest.
How many more decades will this take and will it be too late by the
tie IBM figures it out?

Regards,
David

On 2023-03-02 19:40, David Crayford wrote:

On 2/3/23 22:10, Rick Troth wrote:

On 3/2/23 05:49, David Crayford wrote:

I think 99% of the folks on this forum want a language that can run
in a TSO/ISPF environment hosted in PDS data sets. Lua can do that
and it's orders of magnitudes faster then REXX with the advantage
of package management. The next gen guys don't use TSO/ISPF and
they're going to use Python and couldn't give a hoot about NetRexx.

Lua is great. (Got a link to the MVS version of it?)

Yes
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FLua4z%2FLua4z=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=jeAvZSPCDIzkEhY0X5UMvrcno4CSGEGC%2BHUCTdaGs%2FY%3D=0
and the doc is here
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flua4z.github.io%2FLua4z%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Lb%2Fta5hn0YrHv55d1uZdfLnMh7JIfpIrDLR%2F0bLqyAM%3D=0
which includes the installation instructions.

Disclaimer: lt's my port. It's an EBCDIC port and I tweaked the
package loader to support PDS source data sets. Check out lpeg [1],
it rocks and is frequently used to write transpilers [2]

[1]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.inf.puc-rio.br%2F~roberto%2Flpeg%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=AtRLB0kd74fylPFeqmFPxm2ovG5BawGC03vNSgiUx5U%3D=0
[2]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmoonscript.org%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=gGBIv%2BkBUUO0Y%2BWuxQrK4MoV%2BNy%2FUnHQnXbVm0cvmDQ%3D=0

But language-centric ecosystems not so much. (everything from PIP to
Maven)

We've lost the concept of inter-language calls.
With increasing numbers of new and amazing languages, we seem to be
LESS able to choose and use the right language for the function.

It's great that there is more choice on z/OS now but we are still way
behind other platforms such as Linux. If we want to attract and
retain young talent we need tools that they are familiar with. IBM
are investing heavily on porting tools to z/OS and have a dedicated
team headed up by a distinguished engineer. IBM don't do altruism so
they obviously take this seriously. I see they have a port of rsync
which piqued my interest.
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FZOSOpenTools=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=iO2AsRLJSLWKM7VYXy5euYnP0uHhVm57Qd1COtLdGgY%3D=0

-- R; <><

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

2023-03-02 Thread Mike Schwab

They only got a few dongles out before they shut the program down.

On Thu, Mar 2, 2023 at 10:22 PM David Crayford  wrote:
>
> It's my understanding that IBM made the zPDT available at a much more
> affordable price with quite restrictive T's. I do agree with your
> sentiments. I work with young guys and they raised the same point,
> accessibility to a system to kick tires is an issue for young guys
> considering a career as a mainframer.
>
> On 3/3/23 11:27, David Spiegel wrote:
> > Hi David,
> > You said: "... If we want to attract and retain young talent we need
> > tools that they are familiar with ...".
> > That is not the entire story. IBM also should realize that allowing
> > people to experiment with z/OS via Hercules (for free) is in their
> > best interest.
> > How many more decades will this take and will it be too late by the
> > tie IBM figures it out?
> >
> > Regards,
> > David
> >
> > On 2023-03-02 19:40, David Crayford wrote:
> >> On 2/3/23 22:10, Rick Troth wrote:
> >>> On 3/2/23 05:49, David Crayford wrote:
>  I think 99% of the folks on this forum want a language that can run
>  in a TSO/ISPF environment hosted in PDS data sets. Lua can do that
>  and it's orders of magnitudes faster then REXX with the advantage
>  of package management. The next gen guys don't use TSO/ISPF and
>  they're going to use Python and couldn't give a hoot about NetRexx.
> >>>
> >>>
> >>> Lua is great. (Got a link to the MVS version of it?)
> >>
> >> Yes
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FLua4z%2FLua4z=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=jeAvZSPCDIzkEhY0X5UMvrcno4CSGEGC%2BHUCTdaGs%2FY%3D=0
> >> and the doc is here
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flua4z.github.io%2FLua4z%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Lb%2Fta5hn0YrHv55d1uZdfLnMh7JIfpIrDLR%2F0bLqyAM%3D=0
> >> which includes the installation instructions.
> >>
> >> Disclaimer: lt's my port. It's an EBCDIC port and I tweaked the
> >> package loader to support PDS source data sets. Check out lpeg [1],
> >> it rocks and is frequently used to write transpilers [2]
> >>
> >> [1]
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.inf.puc-rio.br%2F~roberto%2Flpeg%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=AtRLB0kd74fylPFeqmFPxm2ovG5BawGC03vNSgiUx5U%3D=0
> >> [2]
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmoonscript.org%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=gGBIv%2BkBUUO0Y%2BWuxQrK4MoV%2BNy%2FUnHQnXbVm0cvmDQ%3D=0
> >>
> >>
> >>> But language-centric ecosystems not so much. (everything from PIP to
> >>> Maven)
> >>>
> >>> We've lost the concept of inter-language calls.
> >>> With increasing numbers of new and amazing languages, we seem to be
> >>> LESS able to choose and use the right language for the function.
> >>
> >> It's great that there is more choice on z/OS now but we are still way
> >> behind other platforms such as Linux. If we want to attract and
> >> retain young talent we need tools that they are familiar with. IBM
> >> are investing heavily on porting tools to z/OS and have a dedicated
> >> team headed up by a distinguished engineer. IBM don't do altruism so
> >> they obviously take this seriously. I see they have a port of rsync
> >> which piqued my interest.
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FZOSOpenTools=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=iO2AsRLJSLWKM7VYXy5euYnP0uHhVm57Qd1COtLdGgY%3D=0
> >>
> >>
> >>>
> >>>
> >>> -- R; <><
> >>>
> >>> --
> >>> 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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

It's my understanding that IBM made the zPDT available at a much more 
affordable price with quite restrictive T's. I do agree with your 
sentiments. I work with young guys and they raised the same point, 
accessibility to a system to kick tires is an issue for young guys 
considering a career as a mainframer.


On 3/3/23 11:27, David Spiegel wrote:

Hi David,
You said: "... If we want to attract and retain young talent we need 
tools that they are familiar with ...".
That is not the entire story. IBM also should realize that allowing 
people to experiment with z/OS via Hercules (for free) is in their 
best interest.
How many more decades will this take and will it be too late by the 
tie IBM figures it out?


Regards,
David

On 2023-03-02 19:40, David Crayford wrote:

On 2/3/23 22:10, Rick Troth wrote:

On 3/2/23 05:49, David Crayford wrote:
I think 99% of the folks on this forum want a language that can run 
in a TSO/ISPF environment hosted in PDS data sets. Lua can do that 
and it's orders of magnitudes faster then REXX with the advantage 
of package management. The next gen guys don't use TSO/ISPF and 
they're going to use Python and couldn't give a hoot about NetRexx. 



Lua is great. (Got a link to the MVS version of it?)


Yes 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FLua4z%2FLua4z=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=jeAvZSPCDIzkEhY0X5UMvrcno4CSGEGC%2BHUCTdaGs%2FY%3D=0 
and the doc is here 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flua4z.github.io%2FLua4z%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Lb%2Fta5hn0YrHv55d1uZdfLnMh7JIfpIrDLR%2F0bLqyAM%3D=0 
which includes the installation instructions.


Disclaimer: lt's my port. It's an EBCDIC port and I tweaked the 
package loader to support PDS source data sets. Check out lpeg [1], 
it rocks and is frequently used to write transpilers [2]


[1] 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.inf.puc-rio.br%2F~roberto%2Flpeg%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=AtRLB0kd74fylPFeqmFPxm2ovG5BawGC03vNSgiUx5U%3D=0
[2] 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmoonscript.org%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=gGBIv%2BkBUUO0Y%2BWuxQrK4MoV%2BNy%2FUnHQnXbVm0cvmDQ%3D=0



But language-centric ecosystems not so much. (everything from PIP to 
Maven)


We've lost the concept of inter-language calls.
With increasing numbers of new and amazing languages, we seem to be 
LESS able to choose and use the right language for the function.


It's great that there is more choice on z/OS now but we are still way 
behind other platforms such as Linux. If we want to attract and 
retain young talent we need tools that they are familiar with. IBM 
are investing heavily on porting tools to z/OS and have a dedicated 
team headed up by a distinguished engineer. IBM don't do altruism so 
they obviously take this seriously. I see they have a port of rsync 
which piqued my interest. 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FZOSOpenTools=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=iO2AsRLJSLWKM7VYXy5euYnP0uHhVm57Qd1COtLdGgY%3D=0






-- R; <><

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


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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers


Hi David,
You said: "... If we want to attract and retain young talent we need 
tools that they are familiar with ...".
That is not the entire story. IBM also should realize that allowing 
people to experiment with z/OS via Hercules (for free) is in their best 
interest.
How many more decades will this take and will it be too late by the tie 
IBM figures it out?


Regards,
David

On 2023-03-02 19:40, David Crayford wrote:

On 2/3/23 22:10, Rick Troth wrote:

On 3/2/23 05:49, David Crayford wrote:
I think 99% of the folks on this forum want a language that can run 
in a TSO/ISPF environment hosted in PDS data sets. Lua can do that 
and it's orders of magnitudes faster then REXX with the advantage of 
package management. The next gen guys don't use TSO/ISPF and they're 
going to use Python and couldn't give a hoot about NetRexx. 



Lua is great. (Got a link to the MVS version of it?)


Yes 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FLua4z%2FLua4z=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=jeAvZSPCDIzkEhY0X5UMvrcno4CSGEGC%2BHUCTdaGs%2FY%3D=0 
and the doc is here 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flua4z.github.io%2FLua4z%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Lb%2Fta5hn0YrHv55d1uZdfLnMh7JIfpIrDLR%2F0bLqyAM%3D=0 
which includes the installation instructions.


Disclaimer: lt's my port. It's an EBCDIC port and I tweaked the 
package loader to support PDS source data sets. Check out lpeg [1], it 
rocks and is frequently used to write transpilers [2]


[1] 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.inf.puc-rio.br%2F~roberto%2Flpeg%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=AtRLB0kd74fylPFeqmFPxm2ovG5BawGC03vNSgiUx5U%3D=0
[2] 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmoonscript.org%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=gGBIv%2BkBUUO0Y%2BWuxQrK4MoV%2BNy%2FUnHQnXbVm0cvmDQ%3D=0



But language-centric ecosystems not so much. (everything from PIP to 
Maven)


We've lost the concept of inter-language calls.
With increasing numbers of new and amazing languages, we seem to be 
LESS able to choose and use the right language for the function.


It's great that there is more choice on z/OS now but we are still way 
behind other platforms such as Linux. If we want to attract and retain 
young talent we need tools that they are familiar with. IBM are 
investing heavily on porting tools to z/OS and have a dedicated team 
headed up by a distinguished engineer. IBM don't do altruism so they 
obviously take this seriously. I see they have a port of rsync which 
piqued my interest. 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FZOSOpenTools=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=iO2AsRLJSLWKM7VYXy5euYnP0uHhVm57Qd1COtLdGgY%3D=0






-- R; <><

--
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: One more REXX Question

2023-03-02 Thread Paul Gilmartin

This is less a REXX question than an ISPF question, and might get more focused 
replies
in ISPF-LIST.

On Thu, 2 Mar 2023 23:56:52 +, Cameron Conacher wrote:
>...
>When the LMCOPY runs, it writes some IEBCOPY processing messages to a 
>generated file name, which has a high level qualifier of the RACF ID under 
>which the JOB runs.
>If two members are copied, LMCOPY is executed twice, and two IEBCOPY files are 
>generated. if 100 members are copied I get 100 IEBCOPY files generated.
> 
I'm slightly surprised.  But I've used LMCOPY only to copy a PS data set to a 
PDS mdmber.
IEBCOPY isn't needed (or allowed) for that operation.

Likewise, IEBCOPY shouldn't be necessary to copy PDS member to PDS member.

But does LMCOPY replicate the directory user info?  The Ref. doesn't say.

Are the members program objects?

>My question is  this, can I direct all of the IEBCOPY output (assuming it is 
>SYSPRINT) directed to one single output file?
>So, instead of seeing 100 individual IEBCOPY, I only get one single 
>consolidated file with a name of my choosing?

-- 
gil

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

Ransomware in VSAM and DB2

2023-03-02 Thread Tommy Tsui

Hi all.
We are studying to build the tertiary backup. In fact, is it possible to
hack the VSAM dataset during online period, is there any policy to protect
VSAM datasets ?

Thanks for sharing

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

Re: ZOAU [was: RE: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers]


On 3/3/23 00:22, Farley, Peter wrote:

But I found that using them from the z/OS Unix command line embedded in a python script just as in 
the article link is a performance nightmare.  Definitely NOT ready for production use.  The idea is 
good but the implementation is awful.  Take a close look at the implementation of the ZOAU 
dataset-read function for an example of what I saw.  Substantially better performance can be had by 
using the python subprocess.run() function to execute the "cat" shell command to capture 
the z/OS dataset file contents you need in a python list (assuming your file contents will fit in 
available memory, of course; if not use "head" instead to read in chunks at a time)
Spawning a subprocess is a bizarre way to use cat. The idomatic UNIX 
method would be to pipe cat into your Python program and read from stdin.


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

Re: One more REXX Question

2023-03-02 Thread Steve Thompson

Check the JESMSGLOG to see what DD name has been generated/being 
used. You may be able to redirect that to a different DDNAME.


I am in the process of doing something similar with something I 
am doing and I was surprised to read your experience. I don't 
know if I will get all my LM code and looping finished tomorrow 
with all I've got going on, but, I will post out here what my 
results are.


BTW I am running under IKJEFT01, and starting ISPF Not sure 
how you are getting to the LM code.


Regards,
Steve Thompson

On 3/2/2023 6:56 PM, Cameron Conacher wrote:

Hello everyone,
I am using REXX (specifically LMCOPY) to copy PDS members from one library to 
another.
Everything is working just fine. Everything copies as I expect it to.

When the LMCOPY runs, it writes some IEBCOPY processing messages to a generated 
file name, which has a high level qualifier of the RACF ID under which the JOB 
runs.
If two members are copied, LMCOPY is executed twice, and two IEBCOPY files are 
generated. if 100 members are copied I get 100 IEBCOPY files generated.

My question is  this, can I direct all of the IEBCOPY output (assuming it is 
SYSPRINT) directed to one single output file?
So, instead of seeing 100 individual IEBCOPY, I only get one single 
consolidated file with a name of my choosing?

IEBCOPY appears to run under the covers for LMCOPY.
I cannot see anywhere that LMCOPY accepts a parameter indicating where to send 
the IEBCOPY output.

To help clarify things, I can use LMCOPY to copy PDS.LIBRAY1(Member1) to 
PDS.LIBRAY2(Member1) without any issues.
But under the covers LMCOPY seems to run IEBCOPY and I see generated output 
files for IEBCOPY like RACFID.SPF101.IEBCOPY.

Can I tell LMCOPY to inform IEBCOPY to use MYNAME.IEBCOPY.SYSPRINT instead of 
the generated name?

Thanks


Cameron Conacher
Senior Engineer

American Express Canada Inc.
GCICS
2225 Sheppard Avenue East, Toronto, ON  M2J 5C2

cameron.conac...@aexp.com
Office: 1-437-836-5265
Mobile: 1-416-409-5147

https://amex.webex.com/join/cameron.conacher



American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. Box 3204, 
Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no longer 
wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les exp?diteurs par courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers


On 2/3/23 22:10, Rick Troth wrote:

On 3/2/23 05:49, David Crayford wrote:
I think 99% of the folks on this forum want a language that can run 
in a TSO/ISPF environment hosted in PDS data sets. Lua can do that 
and it's orders of magnitudes faster then REXX with the advantage of 
package management. The next gen guys don't use TSO/ISPF and they're 
going to use Python and couldn't give a hoot about NetRexx. 



Lua is great. (Got a link to the MVS version of it?)


Yes https://github.com/Lua4z/Lua4z and the doc is here 
https://lua4z.github.io/Lua4z/ which includes the installation 
instructions.


Disclaimer: lt's my port. It's an EBCDIC port and I tweaked the package 
loader to support PDS source data sets. Check out lpeg [1], it rocks and 
is frequently used to write transpilers [2]


[1] https://www.inf.puc-rio.br/~roberto/lpeg/
[2] https://moonscript.org/


But language-centric ecosystems not so much. (everything from PIP to 
Maven)


We've lost the concept of inter-language calls.
With increasing numbers of new and amazing languages, we seem to be 
LESS able to choose and use the right language for the function.


It's great that there is more choice on z/OS now but we are still way 
behind other platforms such as Linux. If we want to attract and retain 
young talent we need tools that they are familiar with. IBM are 
investing heavily on porting tools to z/OS and have a dedicated team 
headed up by a distinguished engineer. IBM don't do altruism so they 
obviously take this seriously. I see they have a port of rsync which 
piqued my interest. https://github.com/ZOSOpenTools






-- R; <><

--
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: One more REXX Question

2023-03-02 Thread Bob Bridges

Others may tell you authoritatively whether you can or cannot.  I'll just
add that if you can't, it shouldn't be very difficult to have the REXX read
all the generated IEBCOPY files and display their contents in one, and even
have it delete the originals if you feel daring.

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

/* In matters of conscience, the law of majority has no place.  -Mohandas
Karamchand Gandhi (1869-1948) */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Cameron Conacher
Sent: Thursday, March 2, 2023 18:57

I am using REXX (specifically LMCOPY) to copy PDS members from one library
to another.
Everything is working just fine. Everything copies as I expect it to.

When the LMCOPY runs, it writes some IEBCOPY processing messages to a
generated file name, which has a high level qualifier of the RACF ID under
which the JOB runs.
If two members are copied, LMCOPY is executed twice, and two IEBCOPY files
are generated. if 100 members are copied I get 100 IEBCOPY files
generated.

My question is  this, can I direct all of the IEBCOPY output (assuming it is
SYSPRINT) directed to one single output file?
So, instead of seeing 100 individual IEBCOPY, I only get one single
consolidated file with a name of my choosing?

IEBCOPY appears to run under the covers for LMCOPY.
I cannot see anywhere that LMCOPY accepts a parameter indicating where to
send the IEBCOPY output.

To help clarify things, I can use LMCOPY to copy PDS.LIBRAY1(Member1) to
PDS.LIBRAY2(Member1) without any issues.
But under the covers LMCOPY seems to run IEBCOPY and I see generated output
files for IEBCOPY like RACFID.SPF101.IEBCOPY.

Can I tell LMCOPY to inform IEBCOPY to use MYNAME.IEBCOPY.SYSPRINT instead
of the generated name?

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

One more REXX Question

2023-03-02 Thread Cameron Conacher

Hello everyone,
I am using REXX (specifically LMCOPY) to copy PDS members from one library to 
another.
Everything is working just fine. Everything copies as I expect it to.

When the LMCOPY runs, it writes some IEBCOPY processing messages to a generated 
file name, which has a high level qualifier of the RACF ID under which the JOB 
runs.
If two members are copied, LMCOPY is executed twice, and two IEBCOPY files are 
generated. if 100 members are copied I get 100 IEBCOPY files generated.

My question is  this, can I direct all of the IEBCOPY output (assuming it is 
SYSPRINT) directed to one single output file?
So, instead of seeing 100 individual IEBCOPY, I only get one single 
consolidated file with a name of my choosing?

IEBCOPY appears to run under the covers for LMCOPY.
I cannot see anywhere that LMCOPY accepts a parameter indicating where to send 
the IEBCOPY output.

To help clarify things, I can use LMCOPY to copy PDS.LIBRAY1(Member1) to 
PDS.LIBRAY2(Member1) without any issues.
But under the covers LMCOPY seems to run IEBCOPY and I see generated output 
files for IEBCOPY like RACFID.SPF101.IEBCOPY.

Can I tell LMCOPY to inform IEBCOPY to use MYNAME.IEBCOPY.SYSPRINT instead of 
the generated name?

Thanks


Cameron Conacher
Senior Engineer

American Express Canada Inc.
GCICS
2225 Sheppard Avenue East, Toronto, ON  M2J 5C2

cameron.conac...@aexp.com
Office: 1-437-836-5265
Mobile: 1-416-409-5147

https://amex.webex.com/join/cameron.conacher



American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les exp?diteurs par courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.

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

Re: SMP/E RECEIVE ORDER server IP address changes

2023-03-02 Thread Paul Gilmartin

On Thu, 2 Mar 2023 21:14:31 +, Pommier, Rex wrote:

>Hi Kurt,
>
>Will there be more announcements, saying the new IPs and DNS entries are in 
>place and when the old ones will be shut off?
>
And/or update the cited site when "... or soon afterwards." becomes a firm date.

(If IBM owns both IP ranges, couldn't they refer to the same host for a period 
of
toleration?)

(For amusement, try "nslookup blackhole.nyx.net".  -- There was a reason for 
that.)

>-Original Message-
>From: IBM Mainframe Discussion List  On Behalf Of 
>Kurt J. Quackenbush
>Sent: Wednesday, March 1, 2023 12:25 PM
>
>SMP/E RECEIVE ORDER users, take note of the planned IBM order server IP 
>address changes on March 23.
>https://urldefense.com/v3/__https://www.ibm.com/support/pages/node/6856445__;!!KjMRP1Ixj6eLE0Fj!pXhHM269ze-arLEBFFWQyJqtu91Dt4Wh2-Osz8YaAZ4c6aW-y6KknttLgkiGq2_cN5eWzXM9DhDWlN12$
> 

-- 
gil

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

2023-03-02 Thread Andrew Rowley


On 3/03/2023 1:36 am, David Spiegel wrote:
Every time I've watched mainframe Java since OS/90 V1, it has been 
painfully slow. Have you ever watched a WAS startup? ... It takes 
about 15 minutes on the fastest mainframes.


I think that's a reflection on WAS, not Java.

When I was playing with the software drag racing, I compared the times 
from SMF to get an idea of the Java startup etc. overhead.


For a 5 second elapsed time of 5 seconds timed inside the program, SMF 
showed:

C++ : 5.02 seconds elapsed, 4.95 seconds CPU time
Java: 6.16 seconds elapsed, 5.24 seconds CPU time.

So the overhead to start Java looked to be around 1 second elapsed, and 
1/4 second of CPU time. After the startup, Java was as fast as C++ in 
this test.


--
Andrew Rowley
Black Hill Software

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

Re: IBM's Fall From World Dominance

The timer code was different for S/360 and S/370 and I believe that OS/360 set 
some control registers when generated for a S/370.

There were 3rd party mods to increase the memory limits of some models.

From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Thursday, March 2, 2023 4:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM's Fall From World Dominance

I didn’t add that; that's just what happens where altavista.com redirects to.  
What I changed, the second time around, was removing "https:\\" from the URL, 
since I suspected (apparently correctly) that it's what triggered that 
safe-link thing.

I suppose the suffix is added to help inform someone how many dinosaurs are 
using the internet.

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

/* I have adhered to my rule of never criticising any measure of war or policy 
after the event, unless I had before expressed publicly or formally my opinion 
or warning about itLet no one look down on those honourable, well-meaning 
men whose actions are chronicled in these pages, without searching his own 
heart, reviewing his own discharge of public duty, and applying the lessons of 
the past to his future conduct.  -from the preface of "The Gathering Storm", 
volume I of Winston Churchill's history of WWII */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Dave Wade
Sent: Thursday, March 2, 2023 04:39

adding the "fr=altavista" doesn't change the results, what you get is the 
answer according to Microsoft, or more precisely BING.

--- On Wed, 1 Mar 2023 05:43:20 -0500, Bob Bridges  
wrote:
>THAT's how that URL came across?!  Maybe it'll survive better if I
>leave off the "https":
>
>  search.yahoo.com/?fr=altavista

--
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: IBM's Fall From World Dominance

2023-03-02 Thread Bob Bridges

I didn’t add that; that's just what happens where altavista.com redirects to.  
What I changed, the second time around, was removing "https:\\" from the URL, 
since I suspected (apparently correctly) that it's what triggered that 
safe-link thing.

I suppose the suffix is added to help inform someone how many dinosaurs are 
using the internet.

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

/* I have adhered to my rule of never criticising any measure of war or policy 
after the event, unless I had before expressed publicly or formally my opinion 
or warning about itLet no one look down on those honourable, well-meaning 
men whose actions are chronicled in these pages, without searching his own 
heart, reviewing his own discharge of public duty, and applying the lessons of 
the past to his future conduct.  -from the preface of "The Gathering Storm", 
volume I of Winston Churchill's history of WWII */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Dave Wade
Sent: Thursday, March 2, 2023 04:39

adding the "fr=altavista" doesn't change the results, what you get is the 
answer according to Microsoft, or more precisely BING.

--- On Wed, 1 Mar 2023 05:43:20 -0500, Bob Bridges  
wrote:
>THAT's how that URL came across?!  Maybe it'll survive better if I 
>leave off the "https":
>
>  search.yahoo.com/?fr=altavista

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

Re: SMP/E RECEIVE ORDER server IP address changes

Hi Kurt,

Will there be more announcements, saying the new IPs and DNS entries are in 
place and when the old ones will be shut off?

Thanks,

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kurt J. Quackenbush
Sent: Wednesday, March 1, 2023 12:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] SMP/E RECEIVE ORDER server IP address changes

SMP/E RECEIVE ORDER users, take note of the planned IBM order server IP address 
changes on March 23.
https://urldefense.com/v3/__https://www.ibm.com/support/pages/node/6856445__;!!KjMRP1Ixj6eLE0Fj!pXhHM269ze-arLEBFFWQyJqtu91Dt4Wh2-Osz8YaAZ4c6aW-y6KknttLgkiGq2_cN5eWzXM9DhDWlN12$
 

Kurt Quackenbush
IBM  |  z/OS SMP/E and z/OSMF Software Management  |  
ku...@us.ibm.com

Chuck Norris never uses CHECK when he applies PTFs.




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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.

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

Re: ZOAU [was: RE: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers]

2023-03-02 Thread Farley, Peter

That is apparently the issue on the system to which I have access, zoaversion 
there returns "CUT V1.1.1", while the latest version seems to be 1.2.1.

Thanks for the update.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Thursday, March 2, 2023 1:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZOAU [was: RE: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - 
again (Re: zOSMF and zOWE for non-mainframers]

On 3/2/2023 8:22 AM, Farley, Peter wrote:
> One thing I will add from actual testing I have done with ZOAU facilities -- 
> they are HORRIBLY slow.  Yes, you can run them from off-platform - that was 
> their intended raison d'etre - and the fact that you even CAN do that if you 
> really, really need it is a Good Thing (tm).

The original version of ZOAU used SDSF REXX and that was indeed quite slow. 
Ugh...

The latest version uses direct SSI calls written in C and performs much better.
-- 

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

ILC doesn't seem to be a thing in the open source community. It's not an easy 
thing to achieve.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Rick Troth [tro...@gmail.com]
Sent: Thursday, March 2, 2023 9:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF 
and zOWE for non-mainframers

On 3/2/23 05:49, David Crayford wrote:
> I think 99% of the folks on this forum want a language that can run in
> a TSO/ISPF environment hosted in PDS data sets. Lua can do that and
> it's orders of magnitudes faster then REXX with the advantage of
> package management. The next gen guys don't use TSO/ISPF and they're
> going to use Python and couldn't give a hoot about NetRexx.


Lua is great. (Got a link to the MVS version of it?)
But language-centric ecosystems not so much. (everything from PIP to Maven)

We've lost the concept of inter-language calls.
With increasing numbers of new and amazing languages, we seem to be LESS
able to choose and use the right language for the function.


-- R; <><

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

2023-03-02 Thread Mike Schwab

JOL is still available and up to date.

On Thu, Mar 2, 2023 at 6:44 AM Jay Maynard  wrote:
>
> "The mainframe needs to keep pace with the industry."
>
> I certainly hope that whatever the industry is doing that gets adapted to
> the mainframe does so much more cleanly than, say, Python... The absolute
> abortion that is Python's idea of replacing JCL makes COBOL look like APL.
>
> On Thu, Mar 2, 2023 at 6:37 AM David Crayford  wrote:
>
> > On 2/3/23 19:48, René Jansen wrote:
> > >> I think 99% of the folks on this forum want a language that can run in
> > a TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's
> > orders of magnitudes faster then REXX with the advantage of package
> > management. The next gen guys don't use TSO/ISPF and they're going to use
> > Python and couldn't give a hoot about NetRexx.
> > > NetRexx can and does, using the IBM jzos classes, which are delivered
> > with its JVM’s.
> >
> > Hmm, I don't think so. NetRexx programs can not reside in PDS data sets.
> > I don't get the point of NetRexx.
> >
> >
> > > They can do a lot more with conventional MVS than LUA, I am sure.
> >
> > Don't agree. Lua4z has a heap of integrations including TSO/ISPF without
> > VDEFINE. And  you can write packages and applications using PDS data
> > sets. REXX is impoverished in this respect and you can't share state or
> > data structures between modules.
> >
> > /https://lua4z.github.io/Lua4z
> >
> > > Not that anyone would do that, of course, being so much easier with ISPF
> > and Rexx and their shared variable pool. I have built dialogs in COBOL and
> > PL/1 but nothing beats Rexx for that, having not to VDEFINE everything
> > first.
> >
> > That's subjective. I find it much easier to write code in Lua. A
> > programming language that supports OO, meta-programming, functional
> > programming and co-routines with just 20 reserved words is a thing of
> > absolute beauty and a testament to the designers. REXX is a niche
> > language that's only used to any great extend on mainframes and it's
> > popularity is constantly eroding. The mainframe needs to keep pace with
> > the industry.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> Jay Maynard
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

zOSMF and BMC

2023-03-02 Thread Steve Beaver

I have verified that IBM and Broadcom will/or use HTTPS.

 

The only players I don't know what they are doing are

BMC and Precisely.

 

If anyone knows please respond.

 

TIA

 

Steve 


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

Re: Hardware Collection

2023-03-02 Thread Mike Schwab

I bet the archive sites would like a copy.

On Thu, Mar 2, 2023 at 2:58 AM Paul Beesley
<04abe4cebf59-dmarc-requ...@listserv.ua.edu> wrote:
>
> I think I have some Documentation CDs from the late 1990s looking for a new 
> home.
> Contact me off-list of you're interested
>
> Best Regards
> Paul
>
> Days worked: Mon, Tue, Thu, Fri
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Radoslaw Skorupka
> Sent: 01 March 2023 22:32
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Hardware Collection
>
> Caution: External email. Do not open attachments or click links, unless this 
> email comes from a known sender and you know the content is safe.
>
>
> I'm looking for ancient documentation, like IBM Hardware Collection
> (Bookreader)
> I also look for IOCP User Guide for z900. (note: z900, not z/Whatever).
>
> Obviously I'm aware of bitsavers, so I'm looking for other material.
>
> Any clue?
>
>
> It has very little to do with my job. It is just a hobby. I like mainframes.  
> :-)
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> Atos is a trading name used by the Atos group. The trading entity is 
> registered in England and Wales: Atos IT Services UK Limited (registered 
> number 01245534). The registered office is located at: Second Floor, MidCity 
> Place, 71 High Holborn, London, WC1V 6EA. The VAT No. is: GB232327983.
>
> This e-mail and the documents attached are confidential and intended solely 
> for the addressee and may contain confidential or privileged information. If 
> you receive this e-mail in error, you are not authorised to copy, disclose, 
> use or retain it. Please notify the sender immediately and delete this email 
> from your systems. As emails may be intercepted, amended or lost, they are 
> not secure. Atos therefore can accept no liability for any errors or their 
> content. Although Atos endeavours to maintain a virus-free network, we do not 
> warrant that this transmission is virus-free and can accept no liability for 
> any damages resulting from any virus transmitted. The risks are deemed to be 
> accepted by everyone who communicates with Atos by email.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: ZOAU [was: RE: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers]

2023-03-02 Thread Ed Jaffe


On 3/2/2023 8:22 AM, Farley, Peter wrote:

One thing I will add from actual testing I have done with ZOAU facilities -- 
they are HORRIBLY slow.  Yes, you can run them from off-platform - that was 
their intended raison d'etre - and the fact that you even CAN do that if you 
really, really need it is a Good Thing (tm).


The original version of ZOAU used SDSF REXX and that was indeed quite 
slow. Ugh...


The latest version uses direct SSI calls written in C and performs much 
better.



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



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: Hardware instrumentation presentation

2023-03-02 Thread Colin Paice

Someone from IBM sent me a couple of presentations, some of which I had
contributed to.  It covers things like *instruction decode, address
generate,  execute, put away*; parallelism.
How
   L R4,VALUE
   L  R5,0(R4) this has to wait until the previous load has finished,
but other instructions can be processed in parallel.

Data from the L1 cache is faster than data from a different book.
Dont have 2 threads running concurrently sharing the same cache block for
private data.

All good stuff

Colin

On Wed, 1 Mar 2023 at 17:59, Colin Paice  wrote:

> I've been asked to give a talk on performance to a University Computing
> department.
>
> I know the z hardware has in builtin instrumentation which allows you to
> see where the delays were for a particular instruction.  For example this
> load instruction got data from the L3 cache and it took x nano seconds.
>
> Is there a presentation on this?
>
> I remember seeing a presentation (it may have been IBM confidential)
> showing that a Load could be slow, if the data was in a the cache in a book
> 3 ft away, compared to it being in the cache on the chip.
> Also the second time round a loop is faster than the first time because
> the instructions are in the instruction cache.
>
> This was all mind blowing stuff!
>
> Colin
>

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

Re: COMPARE AND TRAP instructions

2023-03-02 Thread Farley, Peter

Thanks very much for pointing out the difference between TRAP2/4 and the 
compare-and-trap (and likewise the load-and-trap) instructions.  Not having 
previously researched them in PoOP, like Steve I AssUMed from the word "trap" 
in their name that they were related to and used the same DUCT trap mechanism 
as TRAP2/4.  Maybe they would have been more intuitively named 
"compare-and-abend" or "compare-and-stop" or "compare-and-signal-error"?

I like to learn one new thing every day, but keeping up by (re-)reading PoOP as 
each new generation adds to the instruction count is a herculean task.  I fear 
my brain will melt from trying to read about the new AI features on the Telum 
chips in z16 machines.  I hardly remember matrix operations at all from my 
college calculus classes decades ago, much less whatever these new AI features 
will do in silicon.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Cole
Sent: Thursday, March 2, 2023 11:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COMPARE AND TRAP instructions

Hi Steve,

You wrote:
>I'm still curious about the conditional trap instructions, e.g. LAT, CIT.
>They have programming notes that imply they're intended for use in
>try-blocks, or assert.  I have no idea if any current compilers use them.

The COMPARE AND TRAP type instructions don't seem particularly 
mysterious to me. They preform a test (compare) and either fall thru 
if the test is false or fail with a PIC 0007-FF data exception 
(0C7-FF at ESTAE time) if the test is true.

They have nothing to do the TRAP2 and TRAP4 instructions, and nothing 
to do with whether or not the task's DUCT has a Trap Handler exit installed.

The "handler" for COMPARE AND TRAPs is your garden variety ESTAE (or 
ESPIE) recovery routine.

The point of the COMPARE AND TRAP instructions is probably 
pipelining. There is no branch that has to be predicted. The hardware 
look-aheads can just presume execution will continue without 
branching. If an interrupt occurs...
* (a) that's a very expensive event anyway,
* So (b) pipeline cache throwaways is not that much of an added burden.
The nature of the COMPARE AND TRAPs is such that the programmer is 
going to use them in situations where the trap action (i.e. the PIC 
0007-FF) will happen only rarely, thus making pipe-linking's 
fall-thru assumptions almost always correct.

I'm not a compiler maven, but these days, with the hardware designers 
and the compiler writers working hand in hand with each other, I'm 
pretty sure the COMPARE AND TRAPs were created at the behest of the 
compiler writers.

Dave Cole, Developer

dbc...@gmail.com (personal)
dbc...@colesoft.com (business)
540-456-6518 (cell)

At 3/2/2023 09:29 AM, Steve Smith wrote:
>I'm still curious about the conditional trap instructions, e.g. LAT, CIT.
>They have programming notes that imply they're intended for use in
>try-blocks, or assert.  I have no idea if any current compilers use them.
>sas
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: CS/CDS instruction

2023-03-02 Thread Ituriel do Neto

Guys,

Thank you, that's exactly what I need. 
I don't know how I didn't see it in Pop


Best Regards

Ituriel do Nascimento Neto
z/OS System Programmer






Em quarta-feira, 1 de março de 2023 às 18:34:12 BRT, Seymour J Metz 
 escreveu: 





In addition to the obvious instructions Phil mentioned, there is also PLO. I 
don't have any relevant performance data.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Ituriel do Neto [03427ec2837d-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, March 1, 2023 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CS/CDS instruction

Hi all,

Is there a similar instruction to CS or CDS, but using 64 bits register ?

I have a double word that contains a counter and using 64 bits instructions
would be faster to increment this value than manipulate it with other storage
areas and an even-odd pair of 32 bits registers.

Thanks in advance


Best Regards

Ituriel do Nascimento Neto
z/OS System Programmer

--
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: [EXTERNAL] Re: Z15 EOM

2023-03-02 Thread Mike Shorkend

I still use the BC/EC nomenclature for lack of a better one.
It comes down to the number of CPs you can have. The z15-T01("EC") has up
to 190 general processors while the z15-T02("BC") is limited to 6. It goes
back to the number of possible drawers on the CEC.

Traditionally, the BC machines have many more sub capacity settings
compared with EC. You can dial the processors from A  to Z , so 26
different capacity settings per CP.
The EC machines have much less granularity




On Thu, 2 Mar 2023 at 19:13, Pommier, Rex  wrote:

> IBM dropped the EC/BC nomenclature, much to my chagrin.  I'm guessing I'm
> not the only one that still refers to the big one as the EC and the smaller
> sibling as the BC, even though IBM doesn't.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Tom Brennan
> Sent: Thursday, March 2, 2023 10:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: Z15 EOM
>
> Didn't IBM drop the BC vs. EC notation a while ago?  I've been calling
> them water-cooled vs. air-cooled.  The number of frames is obviously
> confusing, along with air-cooled model numbers T02 and A01 (and I assume
> A02 on the way) which look like speed/cp settings.
>
> On 3/2/2023 6:43 AM, P H wrote:
> > The slide 91 is NOT the z16 'mid-range/business class' system. Depending
> on the configuration the z16 'high end' system, as announced, comes in 1,
> 2, 3 or 4 racks.l!
> >
> > Sent from Outlook for
> > Android > xj6eLE0Fj!rA4k_tOBFRImng4OTWTF2Hcov3uCOXypF3klop9mtSWE7jN-yDuynqSA1Rcx
> > kxy6kwV1zTq-yFwZSFklGftFxeY$ > 
> > From: IBM Mainframe Discussion List  on
> > behalf of Joe Monk 
> > Sent: Thursday, March 2, 2023 7:29:14 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU 
> > Subject: Re: Z15 EOM
> >
> > "The one rack z16 (aka Business Class) has not yet been announced,"
> >
> > It already exists. See slide 91.
> >
> > https://urldefense.com/v3/__https://ibm-zcouncil.com/wp-content/upload
> > s/2022/05/z16-Technical-Overview-50M-KennyStine.pdf__;!!KjMRP1Ixj6eLE0
> > Fj!rA4k_tOBFRImng4OTWTF2Hcov3uCOXypF3klop9mtSWE7jN-yDuynqSA1Rcxkxy6kwV
> > 1zTq-yFwZSFklSYEm_rc$
> >
> > Joe
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> The information contained in this message is confidential, protected from
> disclosure and may be legally privileged. If the reader of this message is
> not the intended recipient or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby notified
> that any disclosure, distribution, copying, or any action taken or action
> omitted in reliance on it, is strictly prohibited and may be unlawful. If
> you have received this communication in error, please notify us immediately
> by replying to this message and destroy the material in its entirety,
> whether in electronic or hard copy format. Thank you.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Mike Shorkend
m...@shorkend.com
Tel: +972524208743





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

Re: [EXTERNAL] Re: Z15 EOM

IBM dropped the EC/BC nomenclature, much to my chagrin.  I'm guessing I'm not 
the only one that still refers to the big one as the EC and the smaller sibling 
as the BC, even though IBM doesn't.  

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Brennan
Sent: Thursday, March 2, 2023 10:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Z15 EOM

Didn't IBM drop the BC vs. EC notation a while ago?  I've been calling them 
water-cooled vs. air-cooled.  The number of frames is obviously confusing, 
along with air-cooled model numbers T02 and A01 (and I assume
A02 on the way) which look like speed/cp settings.

On 3/2/2023 6:43 AM, P H wrote:
> The slide 91 is NOT the z16 'mid-range/business class' system. Depending on 
> the configuration the z16 'high end' system, as announced, comes in 1, 2, 3 
> or 4 racks.l!
> 
> Sent from Outlook for 
> Android xj6eLE0Fj!rA4k_tOBFRImng4OTWTF2Hcov3uCOXypF3klop9mtSWE7jN-yDuynqSA1Rcx
> kxy6kwV1zTq-yFwZSFklGftFxeY$ > 
> From: IBM Mainframe Discussion List  on 
> behalf of Joe Monk 
> Sent: Thursday, March 2, 2023 7:29:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Z15 EOM
> 
> "The one rack z16 (aka Business Class) has not yet been announced,"
> 
> It already exists. See slide 91.
> 
> https://urldefense.com/v3/__https://ibm-zcouncil.com/wp-content/upload
> s/2022/05/z16-Technical-Overview-50M-KennyStine.pdf__;!!KjMRP1Ixj6eLE0
> Fj!rA4k_tOBFRImng4OTWTF2Hcov3uCOXypF3klop9mtSWE7jN-yDuynqSA1Rcxkxy6kwV
> 1zTq-yFwZSFklSYEm_rc$
> 
> Joe

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


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

Re: COMPARE AND TRAP instructions

2023-03-02 Thread David Cole


Hi Steve,

You wrote:

I'm still curious about the conditional trap instructions, e.g. LAT, CIT.
They have programming notes that imply they're intended for use in
try-blocks, or assert.  I have no idea if any current compilers use them.


The COMPARE AND TRAP type instructions don't seem particularly 
mysterious to me. They preform a test (compare) and either fall thru 
if the test is false or fail with a PIC 0007-FF data exception 
(0C7-FF at ESTAE time) if the test is true.


They have nothing to do the TRAP2 and TRAP4 instructions, and nothing 
to do with whether or not the task's DUCT has a Trap Handler exit installed.


The "handler" for COMPARE AND TRAPs is your garden variety ESTAE (or 
ESPIE) recovery routine.


The point of the COMPARE AND TRAP instructions is probably 
pipelining. There is no branch that has to be predicted. The hardware 
look-aheads can just presume execution will continue without 
branching. If an interrupt occurs...

   * (a) that's a very expensive event anyway,
   * So (b) pipeline cache throwaways is not that much of an added burden.
The nature of the COMPARE AND TRAPs is such that the programmer is 
going to use them in situations where the trap action (i.e. the PIC 
0007-FF) will happen only rarely, thus making pipe-linking's 
fall-thru assumptions almost always correct.


I'm not a compiler maven, but these days, with the hardware designers 
and the compiler writers working hand in hand with each other, I'm 
pretty sure the COMPARE AND TRAPs were created at the behest of the 
compiler writers.




Dave Cole, Developer

dbc...@gmail.com (personal)
dbc...@colesoft.com (business)
540-456-6518 (cell)





At 3/2/2023 09:29 AM, Steve Smith wrote:

I'm still curious about the conditional trap instructions, e.g. LAT, CIT.
They have programming notes that imply they're intended for use in
try-blocks, or assert.  I have no idea if any current compilers use them.
sas


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

Re: ZOAU [was: RE: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers]

2023-03-02 Thread Farley, Peter

One thing I will add from actual testing I have done with ZOAU facilities -- 
they are HORRIBLY slow.  Yes, you can run them from off-platform - that was 
their intended raison d'etre - and the fact that you even CAN do that if you 
really, really need it is a Good Thing (tm).

But I found that using them from the z/OS Unix command line embedded in a 
python script just as in the article link is a performance nightmare.  
Definitely NOT ready for production use.  The idea is good but the 
implementation is awful.  Take a close look at the implementation of the ZOAU 
dataset-read function for an example of what I saw.  Substantially better 
performance can be had by using the python subprocess.run() function to execute 
the "cat" shell command to capture the z/OS dataset file contents you need in a 
python list (assuming your file contents will fit in available memory, of 
course; if not use "head" instead to read in chunks at a time).  Or even use 
David's pyzfile facility, assuming you can get it installed at your shop.

I suppose one could put ZOAU in the class of development tool that is "OK to 
use once or twice a day" but not something you want to use more often than that 
in our CPU-constrained-for-cost environments, at least not until the underlying 
implementation improves dramatically.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jay 
Maynard
Sent: Thursday, March 2, 2023 7:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF 
and zOWE for non-mainframers

I haven't tried to write anything in Rexx, let alone a TCP server. I'd probably 
be inclined to use Go for that, though.

JCL to Python:
https://medium.com/theropod/the-journey-from-jcl-to-python-so-easy-even-an-old-mainframer-can-do-it-f088cc49366a
 

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: Z15 EOM

2023-03-02 Thread Tom Brennan

Oops... I meant water-cooled A01 that looks like an air-cooled speed/cp. 
 Typing too fast.


On 3/2/2023 8:04 AM, Tom Brennan wrote:
Didn't IBM drop the BC vs. EC notation a while ago?  I've been calling 
them water-cooled vs. air-cooled.  The number of frames is obviously 
confusing, along with air-cooled model numbers T02 and A01 (and I assume 
A02 on the way) which look like speed/cp settings.


On 3/2/2023 6:43 AM, P H wrote:
The slide 91 is NOT the z16 'mid-range/business class' system. 
Depending on the configuration the z16 'high end' system, as 
announced, comes in 1, 2, 3 or 4 racks.l!


Sent from Outlook for Android

From: IBM Mainframe Discussion List  on 
behalf of Joe Monk 

Sent: Thursday, March 2, 2023 7:29:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Z15 EOM

"The one rack z16 (aka Business Class) has not yet been announced,"

It already exists. See slide 91.

https://ibm-zcouncil.com/wp-content/uploads/2022/05/z16-Technical-Overview-50M-KennyStine.pdf 



Joe


--
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: Z15 EOM

2023-03-02 Thread zMan

Thanks for all the inside knowledge! /s

Seriously, that page is a keeper.

On Thu, Mar 2, 2023 at 8:17 AM Eric D Rossman  wrote:

> First, let me say that I have NO inside knowledge.
>
> While it doesn't directly answer the question, the official IBM page for
> "IBM Z mainframe hardware product marketing and service life cycle history
> since 1994." can be found at
> https://www.ibm.com/support/pages/ibm-mainframe-life-cycle-history Pages
> 3 and 4 are pretty good (3 is pretty, 4 is good)
>
> So, if the averages hold (I have NO inside knowledge about marketing), HW
> WDFM would be Oct 2023. Again, let me be 100% clear: I have NO inside
> knowledge. This is just based on an official IBM publication.
>
> Did I mention that I have NO inside knowledge, only an educated guess?
>
> As for z17, such a beast does not exist, but I hear that the z16 is quite
> excellent. 

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

Re: Z15 EOM

2023-03-02 Thread Tom Brennan

Didn't IBM drop the BC vs. EC notation a while ago?  I've been calling 
them water-cooled vs. air-cooled.  The number of frames is obviously 
confusing, along with air-cooled model numbers T02 and A01 (and I assume 
A02 on the way) which look like speed/cp settings.


On 3/2/2023 6:43 AM, P H wrote:

The slide 91 is NOT the z16 'mid-range/business class' system. Depending on the 
configuration the z16 'high end' system, as announced, comes in 1, 2, 3 or 4 
racks.l!

Sent from Outlook for Android

From: IBM Mainframe Discussion List  on behalf of Joe Monk 

Sent: Thursday, March 2, 2023 7:29:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Z15 EOM

"The one rack z16 (aka Business Class) has not yet been announced,"

It already exists. See slide 91.

https://ibm-zcouncil.com/wp-content/uploads/2022/05/z16-Technical-Overview-50M-KennyStine.pdf

Joe


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

JCL to Python - was badmouthing REXX

I think this may have been discussed before, but I just read (reread maybe) the 
article mentioned.  Uhh, sure, let's take a 14 line job and change it to a 60+ 
line (without blank lines added for clarity) python script.  

My eye caught this gem of a paragraph toward the end of the article.

Now we have a reasonable replacement for our 14-line JCL. Our new Python 
version of the execution obviously uses more lines than JCL. These lines 
separate code from the input and data needed to run the code effectively. 
Additionally, the code checks input so the system doesn’t have to. Finally, it 
keeps people from the typos that happen when one modifies JCL prior to 
submission. This not only ensures that execution is less error free, but it 
also allows us to create a separation of concern with defaults set at 
configuration time and another set of options defined at execution time.

"This not only ensures that execution is less error free".  Hmm, Freudian slip 
here (?) but the double negative in there means the python script will 
introduce more errors into the execution.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jay 
Maynard
Sent: Thursday, March 2, 2023 6:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again 
(Re: zOSMF and zOWE for non-mainframers

I haven't tried to write anything in Rexx, let alone a TCP server. I'd probably 
be inclined to use Go for that, though.

JCL to Python:
https://urldefense.com/v3/__https://medium.com/theropod/the-journey-from-jcl-to-python-so-easy-even-an-old-mainframer-can-do-it-f088cc49366a__;!!KjMRP1Ixj6eLE0Fj!sV2rmzBI_3NXEz_b9z409tpm3-l1pL0tjnLCN607gy1MfjM-MBCXb-xAbgngG1ACmxR3BKF6IthM6y-f0vDCBQ$

On Thu, Mar 2, 2023 at 6:54 AM David Crayford  wrote:

> On 2/3/23 20:43, Jay Maynard wrote:
> > "The mainframe needs to keep pace with the industry."
> >
> > I certainly hope that whatever the industry is doing that gets 
> > adapted to the mainframe does so much more cleanly than, say, Python...
>
> Like what? Have you ever tried to write a TCP server in REXX?
>
>
> > The absolute abortion that is Python's idea of replacing JCL makes 
> > COBOL
> look like APL.
>
> I haven't seen that. Can you post a link?
>
>

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.

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

Re: [EXTERNAL] Re: Z15 EOM

Actually IBM supports this and has a model of the DS8910F that is designed to 
fit in the 16U of free space in the BC z14 and z15 machines.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gorlinsky
Sent: Thursday, March 2, 2023 8:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Z15 EOM

Some of the configurations of the z/14-16 have enough room to put a "SMALL" 
DASD and VTA appliance in them ... I have seen third parties do this ...

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


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

Re: Z15 EOM

2023-03-02 Thread Ed Jaffe


On 3/2/2023 6:29 AM, Joe Monk wrote:

"The one rack z16 (aka Business Class) has not yet been announced,"

It already exists. See slide 91.

https://ibm-zcouncil.com/wp-content/uploads/2022/05/z16-Technical-Overview-50M-KennyStine.pdf


No. This is just a z16 (3931-A01) that fits in a single rack, but can be 
expanded to more racks.


The business class machine (not yet announced) should have a different 
type/model value and is restricted to a single rack.


For example, the enterprise class z15 is 8561-T01 and the business class 
(single rack) z15 is 8562-T02.



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



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: Z15 EOM

Some of the configurations of the z/14-16 have enough room to put a "SMALL" 
DASD and VTA appliance in them ... I have seen third parties do this ...

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

Re: Z15 EOM

?

© 2022 IBM CorporationIBM z16 Technical Overview_91 is "© 2022 IBM 
CorporationIBM z16 Technical Overview_91 IBM zSystems IBM z16 Configuration: 
PDU based single frame Rear View", not a rack-mounted version.


From: IBM Mainframe Discussion List  on behalf of Joe 
Monk 
Sent: Thursday, March 2, 2023 9:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Z15 EOM

"The one rack z16 (aka Business Class) has not yet been announced,"

It already exists. See slide 91.

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fibm-zcouncil.com%2Fwp-content%2Fuploads%2F2022%2F05%2Fz16-Technical-Overview-50M-KennyStine.pdf=05%7C01%7Csmetz3%40gmu.edu%7C9e5c061cbbc24825426408db1b2abcd0%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638133643887038887%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=YPdbiT3uVFDvzgHbYAxkgOt0tvivl%2FKHnJwrW%2BPv%2BlI%3D=0

Joe





On Thu, Mar 2, 2023 at 7:45 AM Mike Shorkend 
wrote:

> The one rack z16 (aka Business Class) has not yet been announced,so I
> expect the z16+1 is still some time in the not so near future. Likewise the
> EOM for the z15.
>
> On Thu, 2 Mar 2023 at 15:34, Paul Gorlinsky  wrote:
>
> > It should also be noted that the z14 is still a supported processor for
> > zOS 3.1  ...
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> Mike Shorkend
> m...@shorkend.com
> Tel: +972524208743
>
> 
>
> 
>
> --
> 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: Z15 EOM

2023-03-02 Thread P H

The slide 91 is NOT the z16 'mid-range/business class' system. Depending on the 
configuration the z16 'high end' system, as announced, comes in 1, 2, 3 or 4 
racks.l!

Sent from Outlook for Android

From: IBM Mainframe Discussion List  on behalf of Joe 
Monk 
Sent: Thursday, March 2, 2023 7:29:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Z15 EOM

"The one rack z16 (aka Business Class) has not yet been announced,"

It already exists. See slide 91.

https://ibm-zcouncil.com/wp-content/uploads/2022/05/z16-Technical-Overview-50M-KennyStine.pdf

Joe





On Thu, Mar 2, 2023 at 7:45 AM Mike Shorkend 
wrote:

> The one rack z16 (aka Business Class) has not yet been announced,so I
> expect the z16+1 is still some time in the not so near future. Likewise the
> EOM for the z15.
>
> On Thu, 2 Mar 2023 at 15:34, Paul Gorlinsky  wrote:
>
> > It should also be noted that the z14 is still a supported processor for
> > zOS 3.1  ...
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> Mike Shorkend
> m...@shorkend.com
> Tel: +972524208743
>
> 
>
> 
>
> --
> 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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

I chose external for a reason... to my knowledge, the breaches occurred with 
the cooperation of internal staff either purposely or through negligence...

Like RACF admins being lazy and putting things in WARN mode then forgetting 
about it...

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

Respectfully, I think your performance testing is hopelessly outdated. 
Starting a Java application server on z/OS takes a few seconds.


 Starting DataStreamerApplication v1.1.5-SNAPSHOT using Java 1.8.0_351 
on RSD6 with PID 33620928

 No active profile set, falling back to 1 default profile: "default"
 Tomcat initialized with port(s): 9070 (http)
 Starting service [Tomcat]
 Starting Servlet engine: [Apache Tomcat/9.0.60]
 Initializing Spring embedded WebApplicationContext
 Root WebApplicationContext: initialization completed in 3538 ms


On 2/3/23 22:36, David Spiegel wrote:

Hi Paul,
You said: "...JAVA is a good example of this. The mainframe's JAVA 
runtime is written to exploit machine assists and hardware 
instructions that a PC doesn't have..."
Every time I've watched mainframe Java since OS/90 V1, it has been 
painfully slow. Have you ever watched a WAS startup? ... It takes 
about 15 minutes on the fastest mainframes.

Good thing it has assists, otherwise it might take 2 days Feh!

Regards,
David

On 2023-03-02 08:31, Paul Gorlinsky wrote:

After watching this chain for awhile I have a couple of observations:

1) Not all compilers are equal in their tasks especially in the 
optimization area. Some are lazy and just convert the code to pseudo 
code and store it as an executable to remove one layer of processing.


2) The selection of a computer language for a given task should be 
based upon:

  A) Shop standards
  B) Limitations imposed by the OS or OS components the task is 
to be integrated with
  C) The performance requirements, that is does this new widget 
run once a day, hour,minute,second,etc.

  D) Time constraints ... execution time as well as development time
  D) The skill of the programmer


Understanding the PROS and CONS of each computer language is the key 
to a successful project.


Note: that a benchmark run with different languages on a commodity 
computer ( AKA PC ) is NOT transferable to the mainframe. JAVA is a 
good example of this. The mainframe's JAVA runtime is written to 
exploit  machine assists and hardware instructions that a PC doesn't 
have. For example, all the string manipulation instructions.


IMHO



--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

On newer machines there are specific mainframe firmware levels that should be 
kept in sync with the specific versions of the JRE ... otherwise ... the JRE 
takes a longer path

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers


Hi Paul,
You said: "...JAVA is a good example of this. The mainframe's JAVA 
runtime is written to exploit machine assists and hardware instructions 
that a PC doesn't have..."
Every time I've watched mainframe Java since OS/90 V1, it has been 
painfully slow. Have you ever watched a WAS startup? ... It takes about 
15 minutes on the fastest mainframes.

Good thing it has assists, otherwise it might take 2 days Feh!

Regards,
David

On 2023-03-02 08:31, Paul Gorlinsky wrote:

After watching this chain for awhile I have a couple of observations:

1) Not all compilers are equal in their tasks especially in the optimization 
area. Some are lazy and just convert the code to pseudo code and store it as an 
executable to remove one layer of processing.

2) The selection of a computer language for a given task should be based upon:
  A) Shop standards
  B) Limitations imposed by the OS or OS components the task is to be 
integrated with
  C) The performance requirements, that is does this new widget run once a 
day, hour,minute,second,etc.
  D) Time constraints ... execution time as well as development time
  D) The skill of the programmer


Understanding the PROS and CONS of each computer language is the key to a 
successful project.

Note: that a benchmark run with different languages on a commodity computer ( 
AKA PC ) is NOT transferable to the mainframe. JAVA is a good example of this. 
The mainframe's JAVA runtime is written to exploit  machine assists and 
hardware instructions that a PC doesn't have. For example, all the string 
manipulation instructions.

IMHO


  


--
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: Full TRAP feature support

2023-03-02 Thread Ed Jaffe


On 3/2/2023 1:04 AM, David Cole wrote:

Hi Ed,

WRT "ColeSoft acquired zDebug many years ago" I don't recall that we 
ever did that.


We beta tested zDebug (from your old colleague Jeffrey Smith at Farsight 
Systems) back in 2004 and it was excellent.


I remembered it being acquired by Cole not long afterwards. I must have 
remembered incorrectly.


If not Cole, then who acquired that excellent debugger? Is it still 
around as a different product? z/TDF maybe?



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers


Hi Paul,
You said: "...where no externally security breach has occurred…"
If you're saying that no mainframe has ever been hacked, I am certain 
that statement is not true.
The one in particular which comes to mind, involved incompetent security 
admin staff, READ Access to the RACF Database and (i'm guessing some 
insider assistance).
It also involved multi-session software which had vulnerabilities as 
well as lack of protection.


Regards,
David

On 2023-03-02 09:15, Paul Gorlinsky wrote:

IMHO … this is the classic PC v Mainframe programmer debate…
The same people that said Mainframes would be gone … when 40-50% of the worlds 
core data is still in on a mainframe… where a small staff of Systems 
programmers can manage and support entire enterprises and yet thousands of PC 
techs support the server farms… where no externally security breach has 
occurred… and yet PC servers are being held ransom time after time after time …

I still prefer assembler language when I Program on the mainframe… but if 
circumstances dictate… I’ll do cobol pl/1 c Rexx Clist Execs … etc. because I 
am a programmer not a python programmer…

--
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: Z15 EOM

2023-03-02 Thread Joe Monk

"The one rack z16 (aka Business Class) has not yet been announced,"

It already exists. See slide 91.

https://ibm-zcouncil.com/wp-content/uploads/2022/05/z16-Technical-Overview-50M-KennyStine.pdf

Joe





On Thu, Mar 2, 2023 at 7:45 AM Mike Shorkend 
wrote:

> The one rack z16 (aka Business Class) has not yet been announced,so I
> expect the z16+1 is still some time in the not so near future. Likewise the
> EOM for the z15.
>
> On Thu, 2 Mar 2023 at 15:34, Paul Gorlinsky  wrote:
>
> > It should also be noted that the z14 is still a supported processor for
> > zOS 3.1  ...
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> Mike Shorkend
> m...@shorkend.com
> Tel: +972524208743
>
> 
>
> 
>
> --
> 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: Full TRAP feature support

2023-03-02 Thread Steve Smith

I use z/XDC a lot, and I've had SET TRAP2 in my start-up script since I
found out about it.  It has worked seamlessly for me.  The only visible
difference is seeing x'01FF' at breakpoints rather than x'00'.

And it's great that ZDC and other debuggers figured out how to exploit the
facility.

I'm still curious about the conditional trap instructions, e.g. LAT, CIT.
They have programming notes that imply they're intended for use in
try-blocks, or assert.  I have no idea if any current compilers use them.

sas

On Thu, Mar 2, 2023 at 3:06 AM David Cole  wrote:

> Hi Ed,
>
> WRT "ColeSoft acquired zDebug many years ago" I
> don't recall that we ever did that.
>
> WRT "and incorporated much of that technology
> into z/XDC." I'm sure we never did that.
>
> z/XDC does have TRAP2 support, but we didn't
> implemented it until sometime in 2018. (Peter Morrison did the work.)
>
>

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

IMHO … this is the classic PC v Mainframe programmer debate…
The same people that said Mainframes would be gone … when 40-50% of the worlds 
core data is still in on a mainframe… where a small staff of Systems 
programmers can manage and support entire enterprises and yet thousands of PC 
techs support the server farms… where no externally security breach has 
occurred… and yet PC servers are being held ransom time after time after time … 

I still prefer assembler language when I Program on the mainframe… but if 
circumstances dictate… I’ll do cobol pl/1 c Rexx Clist Execs … etc. because I 
am a programmer not a python programmer…

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

2023-03-02 Thread Rick Troth


On 3/2/23 05:49, David Crayford wrote:
I think 99% of the folks on this forum want a language that can run in 
a TSO/ISPF environment hosted in PDS data sets. Lua can do that and 
it's orders of magnitudes faster then REXX with the advantage of 
package management. The next gen guys don't use TSO/ISPF and they're 
going to use Python and couldn't give a hoot about NetRexx. 



Lua is great. (Got a link to the MVS version of it?)
But language-centric ecosystems not so much. (everything from PIP to Maven)

We've lost the concept of inter-language calls.
With increasing numbers of new and amazing languages, we seem to be LESS 
able to choose and use the right language for the function.



-- R; <><

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

I use ooRexx as an integrated procedural language within my mainframe FICON 
attached Virtual Tape Appliance. Why? Because it is the primary procedural 
language used by Systems Programmers on the mainframe. 

We can use a well architected interface and the ADDRESS construct to develop 
and select what environment we want to process commands. Simple well crafted 
interfaces.

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

Hi David,
You said: "... REXX is a niche language that's only used to any great
extend on mainframes and it's popularity is constantly eroding. The
mainframe needs to keep pace with the industry. ..."
1) " used to any great extend on mainframes ..."Last time I looked,
this is a MAINFRAME (my Caps Lock button isn't stuck) discussion group.
Niche or not, who cares?
2) It's popularity is "constantly eroding". Do you have facts to back up
your assertion? Even if true, who cares?
3) The mainframe "... needs to keep pace ..."? With 850,000,000,000
Lines of COBOL running US industry, the Mainframe does not have to keep
pace with anything.

Caveat: I've been programming in Rexx since the day it came out (on
VM/SP). Most of my usage is to simplify Systems Programming tasks, such
as, generating JCL and Commands to implement software updates/upgrades.
(I would never use it in any typical business application; instead, I
would use PL/I or COBOL.) If it takes a few extra nanoseconds, again,
who cares? Finally, learning Rexx is similar to the argument for
learning vi.
Vi comes installed with every *ix. Similarly, Rexx comes installed with
every z/OS and z/VM. (I've worked in places that don't let SysProgs
install anything other than what is licensed. No matter how good Lua is,
it might, therefore, not be available.)

Regards,
David

On 2023-03-02 07:36, David Crayford wrote:

On 2/3/23 19:48, René Jansen wrote:
I think 99% of the folks on this forum want a language that can run
in a TSO/ISPF environment hosted in PDS data sets. Lua can do that
and it's orders of magnitudes faster then REXX with the advantage of
package management. The next gen guys don't use TSO/ISPF and they're
going to use Python and couldn't give a hoot about NetRexx.
NetRexx can and does, using the IBM jzos classes, which are delivered
with its JVM’s.

Hmm, I don't think so. NetRexx programs can not reside in PDS data
sets. I don't get the point of NetRexx.

They can do a lot more with conventional MVS than LUA, I am sure.

Don't agree. Lua4z has a heap of integrations including TSO/ISPF
without VDEFINE. And you can write packages and applications using
PDS data sets. REXX is impoverished in this respect and you can't
share state or data structures between modules.

/https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flua4z.github.io%2FLua4z%2F%2F%2F%2F=05%7C01%7C%7C5d8a2c3555eb47089d8508db1b1ade72%7C84df9e7fe9f640afb435%7C1%7C0%7C638133574493344939%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=DLt1zWGCKau0226D2noVdejr2ioh759Bw0DvdiQlwKw%3D=0

Not that anyone would do that, of course, being so much easier with
ISPF and Rexx and their shared variable pool. I have built dialogs in
COBOL and PL/1 but nothing beats Rexx for that, having not to VDEFINE
everything first.

That's subjective. I find it much easier to write code in Lua. A
programming language that supports OO, meta-programming, functional
programming and co-routines with just 20 reserved words is a thing of
absolute beauty and a testament to the designers. REXX is a niche
language that's only used to any great extend on mainframes and it's
popularity is constantly eroding. The mainframe needs to keep pace
with the industry.

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers



On 2/3/23 21:30, René Jansen wrote:

Not that anyone would do that, of course, being so much easier with ISPF and 
Rexx and their shared variable pool. I have built dialogs in COBOL and PL/1 but 
nothing beats Rexx for that, having not to VDEFINE everything first.

That's subjective. I find it much easier to write code in Lua. A programming 
language that supports OO, meta-programming, functional programming and 
co-routines with just 20 reserved words is a thing of absolute beauty and a 
testament to the designers. REXX is a niche language that's only used to any 
great extend on mainframes and it's popularity is constantly eroding. The 
mainframe needs to keep pace with the industry.


A very true word. And in trying to cast it in the image of Unix, it will always 
be some steps behind, and be an eternal disappointment to next gen people. Look 
at every github project or distribution repo, s390x is always a hanger-on. It 
is a platform of unique strength. What is the point of WebSphere when you have 
CICS? What is the point of then still running WebSphere on Java version 8? Why 
not build the ultimate cloud machine with all the middleware API’s but 
implemented in the best tools there are? Why doesn’t the next ChatGPT run on a 
Z17 with a Prolog/Asm combo using these enormous address spaces with all these 
new instructions on a small number of CPU’s instead of letting those 
datacenters use up all our natural resources with dinky but power hungry - even 
when idling - X86 machines. The problem with all the Z propaganda (still need 
to change that name, IBM) is that all these things about Green and Cloud were 
true, but nobody invested in the software for it, not like the /360 investment 
of the early sixties.

The problem now is pretending that it is leading edge, by running late and 
behind in rebuilding Unix tools from decades ago. The new mainframe should not 
be the old Unix, we have the new Unix in Linux and on the Mac already, and WSL 
for Windows people. IBM does need to invest in software for the mainframe, not 
to divest from it. And it should stop badmouthing its own past.


IBM are investing heavily in porting tools and have some top notch 
talent working on it https://github.com/ZOSOpenTools. Why not ask them 
to port ooRexx? I don't think they will as there just isn't a market for it.




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

Re: Z15 EOM

2023-03-02 Thread rpinion865

To coincide with the AI capabilities of z/OS 3.1, IBM will announce
the HAL-9000 class machine.  I know, IBM had the ES-9000's in the 90's. 




Sent with Proton Mail secure email.

--- Original Message ---
On Thursday, March 2nd, 2023 at 8:44 AM, Mike Shorkend 
 wrote:


> The one rack z16 (aka Business Class) has not yet been announced,so I
> expect the z16+1 is still some time in the not so near future. Likewise the
> EOM for the z15.
> 
> On Thu, 2 Mar 2023 at 15:34, Paul Gorlinsky p...@atsmigrations.com wrote:
> 
> > It should also be noted that the z14 is still a supported processor for
> > zOS 3.1 ...
> > 
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> --
> Mike Shorkend
> m...@shorkend.com
> Tel: +972524208743
> 
> https://www.linkedin.com/in/MikeShorkend/
> 
> 
> https://twitter.com/mikeShorkend
> 
> 
> --
> 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: Z15 EOM

2023-03-02 Thread Mike Shorkend

The one rack z16 (aka Business Class) has not yet been announced,so I
expect the z16+1 is still some time in the not so near future. Likewise the
EOM for the z15.

On Thu, 2 Mar 2023 at 15:34, Paul Gorlinsky  wrote:

> It should also be noted that the z14 is still a supported processor for
> zOS 3.1  ...
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

-- 
Mike Shorkend
m...@shorkend.com
Tel: +972524208743

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

Re: Z15 EOM

It should also be noted that the z14 is still a supported processor for zOS 3.1 
 ...

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

Re: Full TRAP feature support [was: RE: Re: z/OS 3.1 Announcement US Letter]

2023-03-02 Thread Peter Relson

I agree with most of the sentiments expressed here. But that ship has sailed. 
And it is far from true that every operating system provides support for every 
hardware facility.

Back when TRAP2 and TRAP4 were introduced (about 25 years ago), OS/390 
development (it was pre-z/OS) was not even aware of it. And we were shocked to 
learn that debug tool had implemented to the architecture. I hope we can agree 
that that was not appropriate - the OS should have provided an API and debug 
tool should have used it. Whether that API would have been limited to 
authorized users is a different question entirely.

At this point, nothing is going to be done without a strong business 
justification.

Peter Relson
z/OS Core Technology Design


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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

After watching this chain for awhile I have a couple of observations:

1) Not all compilers are equal in their tasks especially in the optimization 
area. Some are lazy and just convert the code to pseudo code and store it as an 
executable to remove one layer of processing.

2) The selection of a computer language for a given task should be based upon:
 A) Shop standards
 B) Limitations imposed by the OS or OS components the task is to be 
integrated with
 C) The performance requirements, that is does this new widget run once a 
day, hour,minute,second,etc. 
 D) Time constraints ... execution time as well as development time
 D) The skill of the programmer


Understanding the PROS and CONS of each computer language is the key to a 
successful project.

Note: that a benchmark run with different languages on a commodity computer ( 
AKA PC ) is NOT transferable to the mainframe. JAVA is a good example of this. 
The mainframe's JAVA runtime is written to exploit  machine assists and 
hardware instructions that a PC doesn't have. For example, all the string 
manipulation instructions. 

IMHO




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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

2023-03-02 Thread René Jansen

On 2 Mar 2023, at 13:36, David Crayford  wrote:
> 
> On 2/3/23 19:48, René Jansen wrote:
>>> I think 99% of the folks on this forum want a language that can run in a 
>>> TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's 
>>> orders of magnitudes faster then REXX with the advantage of package 
>>> management. The next gen guys don't use TSO/ISPF and they're going to use 
>>> Python and couldn't give a hoot about NetRexx.
>> NetRexx can and does, using the IBM jzos classes, which are delivered with 
>> its JVM’s.
> 
> Hmm, I don't think so. NetRexx programs can not reside in PDS data sets. I 
> don't get the point of NetRexx.

This is getting silly. While you would normally compile or run the NetRexx 
interpreter (it can do both) from ZFS there is no reason you could not store 
the source in a PDS. You can run everything from JCL if you wanted. If you 
don’t get the point, I cannot really help you. NetRexx is an oo  variant of the 
Rexx language by the creator of Rexx. It can run everywhere where there is a 
JVM (JRE) available. This is a larger environment than just our PC’s or 
mainframes. I have shown you that it performs rather well, given that it 
produces Java bytecode. It integrates with the environment that hosts the JVM 
rather well, depending on the JVM support for that. The discussion went from 
performance to all over the place.
> 
> 
>> They can do a lot more with conventional MVS than LUA, I am sure.
> 
> Don't agree. Lua4z has a heap of integrations including TSO/ISPF without 
> VDEFINE. And  you can write packages and applications using PDS data sets. 
> REXX is impoverished in this respect and you can't share state or data 
> structures between modules.

> /https://lua4z.github.io/Lua4z
> 
I am not going to compare what Lua4z can do compared to IBM jZos with regard to 
interacting with its environment. I always regarded Java as a safer bet for 
reusability of my code, and I have not been disappointed. I did not encounter a 
lot of ISPF dialogs in Lua yet, and I hope people keep writing them in Rexx or 
Rexx370.

>> Not that anyone would do that, of course, being so much easier with ISPF and 
>> Rexx and their shared variable pool. I have built dialogs in COBOL and PL/1 
>> but nothing beats Rexx for that, having not to VDEFINE everything first.
> 
> That's subjective. I find it much easier to write code in Lua. A programming 
> language that supports OO, meta-programming, functional programming and 
> co-routines with just 20 reserved words is a thing of absolute beauty and a 
> testament to the designers. REXX is a niche language that's only used to any 
> great extend on mainframes and it's popularity is constantly eroding. The 
> mainframe needs to keep pace with the industry.
> 

A very true word. And in trying to cast it in the image of Unix, it will always 
be some steps behind, and be an eternal disappointment to next gen people. Look 
at every github project or distribution repo, s390x is always a hanger-on. It 
is a platform of unique strength. What is the point of WebSphere when you have 
CICS? What is the point of then still running WebSphere on Java version 8? Why 
not build the ultimate cloud machine with all the middleware API’s but 
implemented in the best tools there are? Why doesn’t the next ChatGPT run on a 
Z17 with a Prolog/Asm combo using these enormous address spaces with all these 
new instructions on a small number of CPU’s instead of letting those 
datacenters use up all our natural resources with dinky but power hungry - even 
when idling - X86 machines. The problem with all the Z propaganda (still need 
to change that name, IBM) is that all these things about Green and Cloud were 
true, but nobody invested in the software for it, not like the /360 investment 
of the early sixties.

The problem now is pretending that it is leading edge, by running late and 
behind in rebuilding Unix tools from decades ago. The new mainframe should not 
be the old Unix, we have the new Unix in Linux and on the Mac already, and WSL 
for Windows people. IBM does need to invest in software for the mainframe, not 
to divest from it. And it should stop badmouthing its own past.

There is really nothing better for workloads consisting of batch, CICS, COBOL, 
MQ and DB2 in a sysplex. It could be the base for new workloads but milking out 
the work from the 60-80’s and not investing in it will not bring that future. 
Future Systems (FS) was a great idea if we look at whats left from it, but it 
died because it was so closed that even IBM’s own architects could not 
understand it all in one piece - because it was closely guarded by the internal 
police. We are fortunately past OCO (except for the very things we speak about 
- are we afraid that someone else will build a cloud with it?) and it is 
already clear that open source runs rings around closed source work. It is a 
shame we cannot reuse the many brilliant parts of VM and MVS, DB2 and 
CICS-still. Rexx was

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

Reserved words? We don't need no stinking reserved words. That's one of the 
things I like about PL/I.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Thursday, March 2, 2023 7:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF 
and zOWE for non-mainframers

On 2/3/23 19:48, René Jansen wrote:
>> I think 99% of the folks on this forum want a language that can run in a 
>> TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's 
>> orders of magnitudes faster then REXX with the advantage of package 
>> management. The next gen guys don't use TSO/ISPF and they're going to use 
>> Python and couldn't give a hoot about NetRexx.
> NetRexx can and does, using the IBM jzos classes, which are delivered with 
> its JVM’s.

Hmm, I don't think so. NetRexx programs can not reside in PDS data sets.
I don't get the point of NetRexx.

> They can do a lot more with conventional MVS than LUA, I am sure.

Don't agree. Lua4z has a heap of integrations including TSO/ISPF without
VDEFINE. And  you can write packages and applications using PDS data
sets. REXX is impoverished in this respect and you can't share state or
data structures between modules.

/https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flua4z.github.io%2FLua4z%2F%2F%2F%2F=05%7C01%7Csmetz3%40gmu.edu%7Cfabdfa1c24b14701a95008db1b1add29%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638133574414760901%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=u47BULUorcSSEQnuX3DNC1lpg8Wie6mcyQ4xdL4wFq8%3D=0

> Not that anyone would do that, of course, being so much easier with ISPF and 
> Rexx and their shared variable pool. I have built dialogs in COBOL and PL/1 
> but nothing beats Rexx for that, having not to VDEFINE everything first.

That's subjective. I find it much easier to write code in Lua. A
programming language that supports OO, meta-programming, functional
programming and co-routines with just 20 reserved words is a thing of
absolute beauty and a testament to the designers. REXX is a niche
language that's only used to any great extend on mainframes and it's
popularity is constantly eroding. The mainframe needs to keep pace with
the industry.

--
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: Z15 EOM

2023-03-02 Thread Eric D Rossman

First, let me say that I have NO inside knowledge.

While it doesn't directly answer the question, the official IBM page for "IBM Z 
mainframe hardware product marketing and service life cycle history since 
1994." can be found at 
https://www.ibm.com/support/pages/ibm-mainframe-life-cycle-history Pages 3 and 
4 are pretty good (3 is pretty, 4 is good)

So, if the averages hold (I have NO inside knowledge about marketing), HW WDFM 
would be Oct 2023. Again, let me be 100% clear: I have NO inside knowledge. 
This is just based on an official IBM publication.

Did I mention that I have NO inside knowledge, only an educated guess?

As for z17, such a beast does not exist, but I hear that the z16 is quite 
excellent. 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tommy Tsui
Sent: Thursday, March 2, 2023 2:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Z15 EOM

Hi all

Anyone know when ibm will issue the withdrawal letter for z15. Anyone planning 
to upgrade z17?  It seems a bit late due to COVID-19?

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

Due to shop standard constraints I end up writing a client and a server in 
COBOL for a state agency. Code is still in use after 15 years and has not 
required any maintenance.

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

A good compilers does, e.g., flow analysis, to optimize the generated code. It 
may be difficult to hand optimize well enough to beat a good compiler and still 
keep the code readable.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Colin Paice [colinpai...@gmail.com]
Sent: Thursday, March 2, 2023 2:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF 
and zOWE for non-mainframers

I think it is horses for courses.  Someone once said to me something along
the lines of ..

If you run it once a day write it in rexx (or Python)
If you run it once an hour - write it in Java
If you run it once a second write it in C
If you run it 1000 times a second - write it in Assembler.

It is not just a matter of performance - how much of your time do you want
to invest in writing the program.  The more time you spend - the better it
should be.
If it is good enough - is that OK ?
Colin

On Thu, 2 Mar 2023 at 04:25, David Crayford  wrote:

> After struggling with NetRexx, I've found that it could benefit from
> being as user-friendly as Kotlin or Groovy if the maintainers want to
> attract more users. On my machine, NetRexx is slower than Python but
> still respectable.
>
> However, both Python and NetRexx are outperformed by highly optimized
> Java solutions. Go is also impressive and available on z/OS using the
> IBM SDK.
>
> It's important to note that NetRexx is not ooRexx, and the discussion
> was focused on the poor performance of ooRexx. While some may choose to
> bridge NetRexx with Java, I personally find it more convenient to use
> Kotlin or Groovy instead.
>
>
> ❯ python3 PrimePy.py
> Passes: 6699, Time: 5.000532913953066, Avg: 0.0007464596079941881,
> Limit: 100, Count: 78498, Valid: True
> emillynge_numpy; 6699;5.000532913953066;1;algorithm=base,faithful=no,bits=8
>
> ❯ java -cp ~/NetRexx-4.04-GA/lib/NetRexxF.jar:. PrimeNetRexx
> joss_NetRexx;5743;5.000354;1;algorithm=base,bits=8,faithful=yes
>
> Optimized Java
>
> ❯ ./runSolution.sh
> chrvanorleI32;6197;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI32;19191;5.003000;4;algorithm=base,faithful=yes,bits=1
> chrvanorleI32C;7511;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI32C;21451;5.003000;4;algorithm=base,faithful=yes,bits=1
> chrvanorleI64;5957;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI64;18471;5.015000;4;algorithm=base,faithful=yes,bits=1
> chrvanorleI64C;7161;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI64C;21167;5.006000;4;algorithm=base,faithful=yes,bits=1
>
> chrvanorleI64PatternCalc;9308;5.00;1;algorithm=other,faithful=yes,bits=1
>
> chrvanorleI64PatternCalc;29123;5.004000;4;algorithm=other,faithful=yes,bits=1
> chrvanorleI8;4946;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI8;14963;5.016000;4;algorithm=base,faithful=yes,bits=1
> chrvanorleI32CUnroll;7927;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI32CUnroll;25650;5.006000;4;algorithm=base,faithful=yes,bits=1
>
> chrvanorleStrided32Blocks16k;12069;5.00;1;algorithm=base,faithful=yes,bits=1
>
> chrvanorleStrided32Blocks16k;37190;5.009000;4;algorithm=base,faithful=yes,bits=1
>
> ❯ go run .
> Run for 5.0 seconds using 12 workers to builing a sieve up to 100...
> Passes: 19506, Time: 5000 ms, Avg: 256336 ns/op, Limit: 100, Count1:
> 78498, Count2: 78498, Valid: true
> kpym-go-multi;19506;5.96;4;algorithm=base,faithful=yes
>
>
> On 2/3/23 00:54, René Jansen wrote:
> > so this should work for you:
> >
> > ➜  test git:(master) ✗ cat hello.nrx
> > import java.lang.String
> >
> > say 'hello java' System.getProperty("java.version")
> >
> > loop i=long 0 to 10
> >   hello(i)
> > end
> >
> > loop i=long 0 to 10
> >   hello(java.lang.String(i))
> > end
> >
> > method hello(j)
> >say "hello" j
> >
> >method hello(j=long)
> >  say "hello long" j
> >
> >method hello(j=java.lang.String)
> >  say "hello String" j
> > ➜  test git:(master) ✗ unset CLASSPATH
> > ➜  test git:(master) ✗ echo $CLASSPATH
> >
> > ➜  test git:(master) ✗ java -jar NetRexxC.jar hello
> > NetRexx portable processor 4.05-beta build 374-20230213-1052
> > Copyright (c) RexxLA, 2011,2023.   All rights reserved.
> > Parts Copyright (c) IBM Corporation, 1995,2008.
> > Program hello.nrx
> >  constructor hello(Rexx)
> >  constructor hello(long)
> >  constructor hello(String)
> > Compilation of 'hello.nrx' successful
> > ➜  test git:(master) ✗
> >
> > I have a global CLASSPATH, and only for specific projects I have a -cp
> on the command line for Make or Ninja, to have control over versions and
> libraries.
> > A global classpath enables me to check if all code is still compatible
> with the combination of releases from different libraries I use.
> > But as you see it is not really needed. We are not mandating anything,
>

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

On 2/3/23 20:57, Jay Maynard wrote:

I haven't tried to write anything in Rexx, let alone a TCP server. I'd
probably be inclined to use Go for that, though.

JCL to Python:
https://medium.com/theropod/the-journey-from-jcl-to-python-so-easy-even-an-old-mainframer-can-do-it-f088cc49366a

Totally agree with you. JCL is what it is. The data set I/O classes are
even more pathetic which is why I wrote https://github.com/daveyc/pyzfile

On Thu, Mar 2, 2023 at 6:54 AM David Crayford wrote:

On 2/3/23 20:43, Jay Maynard wrote:

"The mainframe needs to keep pace with the industry."

I certainly hope that whatever the industry is doing that gets adapted to
the mainframe does so much more cleanly than, say, Python...

Like what? Have you ever tried to write a TCP server in REXX?

The absolute abortion that is Python's idea of replacing JCL makes COBOL

look like APL.

I haven't seen that. Can you post a link?

On Thu, Mar 2, 2023 at 6:37 AM David Crayford

wrote:

On 2/3/23 19:48, René Jansen wrote:

I think 99% of the folks on this forum want a language that can run in

a TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's
orders of magnitudes faster then REXX with the advantage of package
management. The next gen guys don't use TSO/ISPF and they're going to

use

Python and couldn't give a hoot about NetRexx.

NetRexx can and does, using the IBM jzos classes, which are delivered

with its JVM’s.

Hmm, I don't think so. NetRexx programs can not reside in PDS data sets.
I don't get the point of NetRexx.

They can do a lot more with conventional MVS than LUA, I am sure.

Don't agree. Lua4z has a heap of integrations including TSO/ISPF without
VDEFINE. And you can write packages and applications using PDS data
sets. REXX is impoverished in this respect and you can't share state or
data structures between modules.

/https://lua4z.github.io/Lua4z

Not that anyone would do that, of course, being so much easier with

ISPF

and Rexx and their shared variable pool. I have built dialogs in COBOL

and

PL/1 but nothing beats Rexx for that, having not to VDEFINE everything
first.

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

2023-03-02 Thread Jay Maynard

I haven't tried to write anything in Rexx, let alone a TCP server. I'd
probably be inclined to use Go for that, though.

JCL to Python:
https://medium.com/theropod/the-journey-from-jcl-to-python-so-easy-even-an-old-mainframer-can-do-it-f088cc49366a

On Thu, Mar 2, 2023 at 6:54 AM David Crayford  wrote:

> On 2/3/23 20:43, Jay Maynard wrote:
> > "The mainframe needs to keep pace with the industry."
> >
> > I certainly hope that whatever the industry is doing that gets adapted to
> > the mainframe does so much more cleanly than, say, Python...
>
> Like what? Have you ever tried to write a TCP server in REXX?
>
>
> > The absolute abortion that is Python's idea of replacing JCL makes COBOL
> look like APL.
>
> I haven't seen that. Can you post a link?
>
>
> >
> > On Thu, Mar 2, 2023 at 6:37 AM David Crayford 
> wrote:
> >
> >> On 2/3/23 19:48, René Jansen wrote:
>  I think 99% of the folks on this forum want a language that can run in
> >> a TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's
> >> orders of magnitudes faster then REXX with the advantage of package
> >> management. The next gen guys don't use TSO/ISPF and they're going to
> use
> >> Python and couldn't give a hoot about NetRexx.
> >>> NetRexx can and does, using the IBM jzos classes, which are delivered
> >> with its JVM’s.
> >>
> >> Hmm, I don't think so. NetRexx programs can not reside in PDS data sets.
> >> I don't get the point of NetRexx.
> >>
> >>
> >>> They can do a lot more with conventional MVS than LUA, I am sure.
> >> Don't agree. Lua4z has a heap of integrations including TSO/ISPF without
> >> VDEFINE. And  you can write packages and applications using PDS data
> >> sets. REXX is impoverished in this respect and you can't share state or
> >> data structures between modules.
> >>
> >> /https://lua4z.github.io/Lua4z
> >>
> >>> Not that anyone would do that, of course, being so much easier with
> ISPF
> >> and Rexx and their shared variable pool. I have built dialogs in COBOL
> and
> >> PL/1 but nothing beats Rexx for that, having not to VDEFINE everything
> >> first.
> >>
> >> That's subjective. I find it much easier to write code in Lua. A
> >> programming language that supports OO, meta-programming, functional
> >> programming and co-routines with just 20 reserved words is a thing of
> >> absolute beauty and a testament to the designers. REXX is a niche
> >> language that's only used to any great extend on mainframes and it's
> >> popularity is constantly eroding. The mainframe needs to keep pace with
> >> the industry.
> >>
> >> --
> >> 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
>


-- 
Jay Maynard

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers


On 2/3/23 20:43, Jay Maynard wrote:

"The mainframe needs to keep pace with the industry."

I certainly hope that whatever the industry is doing that gets adapted to
the mainframe does so much more cleanly than, say, Python...


Like what? Have you ever tried to write a TCP server in REXX?



The absolute abortion that is Python's idea of replacing JCL makes COBOL look 
like APL.


I haven't seen that. Can you post a link?




On Thu, Mar 2, 2023 at 6:37 AM David Crayford  wrote:


On 2/3/23 19:48, René Jansen wrote:

I think 99% of the folks on this forum want a language that can run in

a TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's
orders of magnitudes faster then REXX with the advantage of package
management. The next gen guys don't use TSO/ISPF and they're going to use
Python and couldn't give a hoot about NetRexx.

NetRexx can and does, using the IBM jzos classes, which are delivered

with its JVM’s.

Hmm, I don't think so. NetRexx programs can not reside in PDS data sets.
I don't get the point of NetRexx.



They can do a lot more with conventional MVS than LUA, I am sure.

Don't agree. Lua4z has a heap of integrations including TSO/ISPF without
VDEFINE. And  you can write packages and applications using PDS data
sets. REXX is impoverished in this respect and you can't share state or
data structures between modules.

/https://lua4z.github.io/Lua4z


Not that anyone would do that, of course, being so much easier with ISPF

and Rexx and their shared variable pool. I have built dialogs in COBOL and
PL/1 but nothing beats Rexx for that, having not to VDEFINE everything
first.

That's subjective. I find it much easier to write code in Lua. A
programming language that supports OO, meta-programming, functional
programming and co-routines with just 20 reserved words is a thing of
absolute beauty and a testament to the designers. REXX is a niche
language that's only used to any great extend on mainframes and it's
popularity is constantly eroding. The mainframe needs to keep pace with
the industry.

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

2023-03-02 Thread Jay Maynard

"The mainframe needs to keep pace with the industry."

I certainly hope that whatever the industry is doing that gets adapted to
the mainframe does so much more cleanly than, say, Python... The absolute
abortion that is Python's idea of replacing JCL makes COBOL look like APL.

On Thu, Mar 2, 2023 at 6:37 AM David Crayford  wrote:

> On 2/3/23 19:48, René Jansen wrote:
> >> I think 99% of the folks on this forum want a language that can run in
> a TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's
> orders of magnitudes faster then REXX with the advantage of package
> management. The next gen guys don't use TSO/ISPF and they're going to use
> Python and couldn't give a hoot about NetRexx.
> > NetRexx can and does, using the IBM jzos classes, which are delivered
> with its JVM’s.
>
> Hmm, I don't think so. NetRexx programs can not reside in PDS data sets.
> I don't get the point of NetRexx.
>
>
> > They can do a lot more with conventional MVS than LUA, I am sure.
>
> Don't agree. Lua4z has a heap of integrations including TSO/ISPF without
> VDEFINE. And  you can write packages and applications using PDS data
> sets. REXX is impoverished in this respect and you can't share state or
> data structures between modules.
>
> /https://lua4z.github.io/Lua4z
>
> > Not that anyone would do that, of course, being so much easier with ISPF
> and Rexx and their shared variable pool. I have built dialogs in COBOL and
> PL/1 but nothing beats Rexx for that, having not to VDEFINE everything
> first.
>
> That's subjective. I find it much easier to write code in Lua. A
> programming language that supports OO, meta-programming, functional
> programming and co-routines with just 20 reserved words is a thing of
> absolute beauty and a testament to the designers. REXX is a niche
> language that's only used to any great extend on mainframes and it's
> popularity is constantly eroding. The mainframe needs to keep pace with
> the industry.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Jay Maynard

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers


On 2/3/23 19:48, René Jansen wrote:

I think 99% of the folks on this forum want a language that can run in a 
TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's orders 
of magnitudes faster then REXX with the advantage of package management. The 
next gen guys don't use TSO/ISPF and they're going to use Python and couldn't 
give a hoot about NetRexx.

NetRexx can and does, using the IBM jzos classes, which are delivered with its 
JVM’s.


Hmm, I don't think so. NetRexx programs can not reside in PDS data sets. 
I don't get the point of NetRexx.




They can do a lot more with conventional MVS than LUA, I am sure.


Don't agree. Lua4z has a heap of integrations including TSO/ISPF without 
VDEFINE. And  you can write packages and applications using PDS data 
sets. REXX is impoverished in this respect and you can't share state or 
data structures between modules.


/https://lua4z.github.io/Lua4z


Not that anyone would do that, of course, being so much easier with ISPF and 
Rexx and their shared variable pool. I have built dialogs in COBOL and PL/1 but 
nothing beats Rexx for that, having not to VDEFINE everything first.


That's subjective. I find it much easier to write code in Lua. A 
programming language that supports OO, meta-programming, functional 
programming and co-routines with just 20 reserved words is a thing of 
absolute beauty and a testament to the designers. REXX is a niche 
language that's only used to any great extend on mainframes and it's 
popularity is constantly eroding. The mainframe needs to keep pace with 
the industry.


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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

2023-03-02 Thread René Jansen

> On 2 Mar 2023, at 11:49, David Crayford  wrote:
> 
> That shouldn't make any difference. SquareRoot is only called once. I had to 
> laugh when I noticed that it was implemented using Newton–Raphson in REXX. 
> How can a programming language not implement a sqrt() function?
> 

You might want to verify that statement. It is not called once but but every 
time there is an Erastothenes object created. That, of course, explains the 
difference when replacing the squareroot method.
Which language does not implement a sqrt function? NetRexx does not, because 
Java has a perfectly and transparantly usable java.lang.Math.sqrt(). We might 
improve on it with unlimited precision decimals, though, one day.

> 
> How do I build NetRexx programs using Gradle or Maven! It kind of sucks 
> having to rub two sticks together using the command line!
> 
You can if you must. Maven will documented in the upcoming 4.05 release 
documentation. When fixing the Kotlin Gradle build I’ll try to document that 
with NetRexx builds.

> 
> I think 99% of the folks on this forum want a language that can run in a 
> TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's orders 
> of magnitudes faster then REXX with the advantage of package management. The 
> next gen guys don't use TSO/ISPF and they're going to use Python and couldn't 
> give a hoot about NetRexx.

NetRexx can and does, using the IBM jzos classes, which are delivered with its 
JVM’s. They can do a lot more with conventional MVS than LUA, I am sure. Not 
that anyone would do that, of course, being so much easier with ISPF and Rexx 
and their shared variable pool. I have built dialogs in COBOL and PL/1 but 
nothing beats Rexx for that, having not to VDEFINE everything first.

Who knows what the next gen guys and girls are going to do? It is not what I am 
worrying about; just wanted to correct some untruths.

René.

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

Re: Z15 EOM

2023-03-02 Thread P H

At the risk of stating the obvious, the date will be made known via an 
announcement letter. As yet I haven't seen one 

z17??

Regards

Parwez Hamid

From: IBM Mainframe Discussion List  on behalf of 
Tommy Tsui 
Sent: 02 March 2023 07:36
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Z15 EOM

Hi all

Anyone know when ibm will issue the withdrawal letter for z15. Anyone
planning to upgrade z17?  It seems a bit late due to COVID-19?

--
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: Hardware Collection

2023-03-02 Thread Radoslaw Skorupka


Paul,
I'd like to contact you, however I don't see your email address.

Mine is: R.Skorupka (at) hotmail-dot-com


Regarding CDs - would it be possible to share it using google drive, 
dropbox or other service?


Regards
--
Radoslaw Skorupka
Lodz, Poland



W dniu 02.03.2023 o 09:57, Paul Beesley pisze:

I think I have some Documentation CDs from the late 1990s looking for a new 
home.
Contact me off-list of you're interested

Best Regards
Paul

Days worked: Mon, Tue, Thu, Fri

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: 01 March 2023 22:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Hardware Collection

Caution: External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.


I'm looking for ancient documentation, like IBM Hardware Collection
(Bookreader)
I also look for IOCP User Guide for z900. (note: z900, not z/Whatever).

Obviously I'm aware of bitsavers, so I'm looking for other material.

Any clue?


It has very little to do with my job. It is just a hobby. I like mainframes.  
:-)

--
Radoslaw Skorupka
Lodz, Poland



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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers