Fwd: Banks migrate from mainframes to AI-driven cloud tech

2024-02-09 Thread Mark Regan
https://www.finextra.com/newsarticle/43673/banks-migrate-from-mainframes-to-ai-driven-cloud-tech
 

 

​Regards,

 

Mark Regan, K8MTR General, EN80tg

CTO1 USNR-Retired (1969-1991), 

  RUENAAA/CNO WASHINGTON DC//OP-009QCP (1976-1979)

Nationwide Insurance, Retired (1986-2017),

  z/OS Network Infrastructure Engineering Consultant

Email: marktre...@gmail.com  

LinkedIn:  https://www.linkedin.com/in/mark-t-regan 

 

 


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


Re: XTL64E_EXTENTADDR

2024-02-09 Thread Joseph Reichman
Hi 

What I was trying to do is that after you had helped me understand rb chain I 
was trying to get the extents of the load module to ensure that SDWAEC1 and 
SDWAEC2 fall in the range for the appropriate load module before I display the 
offsets

thanks   

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter Relson
Sent: Wednesday, February 7, 2024 1:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XTL64E_EXTENTADDR

In contents supervisor speak, an extent list contains header information and 
then information about the length and address of each (module) extent (whether 
mapped by IHAXTLST or IHAXTL64. 

As the name implies, XTL64E_EXTENTADDR contains the address of the extent for 
this entry. And, not surprising, there is a similar field, also appropriately 
named, that contains the length of the extent.
Applying both to XTLST and XTL64, it is relatively uncommon to need to know the 
information about the extents unless dumping the module. The entry point 
address is more common to use. Since you didn't provide any information about 
what you were intending to do with the information, I have no idea which would 
be better for you.
Peter Relsonz/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

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


Re: Missing LMOD doing APPLY

2024-02-09 Thread Kurt Quackenbush
> We are using the waves and ripples sequence in the Program Directory.  This 
> error occurs in Wave 0.



> We found that LMOD IEWDLR00 is created in HBB77E0.F6(HBB77E0), STEP 17.  
> Looks like part of Wave 1A.

> Is it possible that running the DDDEFs for Wave 1 and Wave 2 before Wave 0 
> APPLY was completed has messed up things, i.e. pointing to incorrect 
> libraries?

No, the presence of DDDEF entries should not affect or cause this error.

If you have not already, I suggest you open a support case with IBM as I think 
we need to look at your output to debug this further.  IEWDLR00 defined I Wave 
1A, after Wave 0, is a head scratcher.  There should be no reference to 
IEWDLR00 in Wave 0.  Are you installing into a brand new empty target zone, or 
did you make a copy of the target zone from a prior release?

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


HLQ of Page Dataset Names

2024-02-09 Thread Mark Jacobs
I seem to recall, but can't find anything that confirms my recollection that 
certain HLQs such as SYS1 and PAGE have special powers as relating to systems 
programmer type management activities. Can anyone point me to the documentation 
if true, or tell me I'm incorrect if I am? Thanks.

Mark Jacobs

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com

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


Re: HLQ of Page Dataset Names

2024-02-09 Thread David Elliot
Are you talking about choosing your own HLQ for page datasets?



On Fri, Feb 9, 2024, 2:54 PM Mark Jacobs <
0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:

> I seem to recall, but can't find anything that confirms my recollection
> that certain HLQs such as SYS1 and PAGE have special powers as relating to
> systems programmer type management activities. Can anyone point me to the
> documentation if true, or tell me I'm incorrect if I am? Thanks.
>
> Mark Jacobs
>
> Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted
> email.
>
> GPG Public Key -
> https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
>
> --
> 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: Missing LMOD doing APPLY

2024-02-09 Thread Gord Neill
It's a brand new empty target zone.  We're using brand new hardware, so our 
only source is what's on the COD system.  We got rid of all the existing DDDEF 
entries for all Waves, then just rebuilt the ones for Wave 0.  You're right, it 
made no difference.

I guess next step is to open a ticket with IBM.  Thx.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kurt Quackenbush
Sent: Friday, February 9, 2024 9:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Missing LMOD doing APPLY

Caution: This email is originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


> We are using the waves and ripples sequence in the Program Directory.  This 
> error occurs in Wave 0.



> We found that LMOD IEWDLR00 is created in HBB77E0.F6(HBB77E0), STEP 17.  
> Looks like part of Wave 1A.

> Is it possible that running the DDDEFs for Wave 1 and Wave 2 before Wave 0 
> APPLY was completed has messed up things, i.e. pointing to incorrect 
> libraries?

No, the presence of DDDEF entries should not affect or cause this error.

If you have not already, I suggest you open a support case with IBM as I think 
we need to look at your output to debug this further.  IEWDLR00 defined I Wave 
1A, after Wave 0, is a head scratcher.  There should be no reference to 
IEWDLR00 in Wave 0.  Are you installing into a brand new empty target zone, or 
did you make a copy of the target zone from a prior release?

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

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


Re: HLQ of Page Dataset Names

2024-02-09 Thread Styles, Andy (CIO GS&S - Core Infrastructure & IT Operations )
Classification: Public

Certainly as far as catalog entries go, page datasets have some super powers, 
like SYS1. From experience, the catalog that the page datasets (and others) 
were originally defined in has no bearing on the catalog currently in use. From 
the DEFINE CLUSTER RECATALOG manual entry (though I see what appears to be an 
editorial side note is still included as text even in the 3.1 manual 😊).


RECATALOG
Recreates the catalog entries if valid VVDS entries are found on the primary 
VVDS volume. If they are not, the command ends.
When recataloging entries (including zFS files) with indirect volsers, the VVDS 
on the substituted volser must contain a valid NVRs or VVRs that match the 
entry name.

Catalog entries can be re-created only in the catalog specified in the VVR 
except for entries that are swap space, page space, or SYS1 data sets. Change 
this to Catalog entries can be re-created only in the catalog specified in the 
VVR except for entries that are swap space, page space, SYS1 data sets or 
single volume zFS VSAM Linear data sets with an indirect volume serial.


Andy Styles
z/Series Systems Programmer


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Elliot
Sent: Friday, February 9, 2024 3:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: HLQ of Page Dataset Names

[Some people who received this message don't often get email from 
05829bddcbe4-dmarc-requ...@listserv.ua.edu. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

*** This email is from an external source - be careful of attachments and 
links. Please report suspicious emails ***

Are you talking about choosing your own HLQ for page datasets?



On Fri, Feb 9, 2024, 2:54 PM Mark Jacobs < 
0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:

> I seem to recall, but can't find anything that confirms my
> recollection that certain HLQs such as SYS1 and PAGE have special
> powers as relating to systems programmer type management activities.
> Can anyone point me to the documentation if true, or tell me I'm incorrect if 
> I am? Thanks.
>
> Mark Jacobs
>
> Sent from
> [ProtonMail](https://protonmail.com/), Swiss-based encrypted email.
>
> GPG Public Key -
> https://api/.
> protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40proton
> mail.com&data=05%7C02%7CAndy.Styles%40lloydsbanking.com%7Ced61797b2ea3
> 44ef309808dc298256a3%7C3ded2960214a46ff8cf4611f125e2398%7C0%7C0%7C6384
> 30886983227735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=jlNqycjuJx9RK%2
> BxmZhesNpzxnm52rIxLW8ON9tZLtRQ%3D&reserved=0
>
> --
> 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
Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC95000. Telephone: 0131 225 4555.

Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. 
Registered in England and Wales no. 2065. Telephone 0207626 1500.

Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC327000. Telephone: 03457 801 801.

Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London 
EC2V 7HN. Registered in England and Wales no. 10399850.

Scottish Widows Schroder Personal Wealth Limited. Registered Office: 25 Gresham 
Street, London EC2V 7HN. Registered in England and Wales no. 11722983.

Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are 
authorised by the Prudential Regulation Authority and regulated by the 
Financial Conduct Authority and Prudential Regulation Authority.

Scottish Widows Schroder Personal Wealth Limited is authorised and regulated by 
the Financial Conduct Authority.

Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned 
subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets 
Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 
6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht 
Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets 
Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für 
Finanzdienstleistungsaufsicht.

Halifax is a division of Bank of Scotland plc.

HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in 
Scotland no. SC218813.



This e-mail (including any attachments) is private and confidential and may 
contain privileged material. If you have received this e-mail in error, please 
notify the sender and delete it (including any attachments) immediately. You 
must n

Re: HLQ of Page Dataset Names

2024-02-09 Thread Mark Jacobs
Yes, we're currently using the value of &SYSNAME as the HLQ for the page 
datasets. I was wondering if there's any special powers available for the HLQ 
of SYS1 or PAGE.

Mark Jacobs 

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com


On Friday, February 9th, 2024 at 10:16 AM, David Elliot 
<05829bddcbe4-dmarc-requ...@listserv.ua.edu> wrote:

> Are you talking about choosing your own HLQ for page datasets?
> 
> 
> 
> On Fri, Feb 9, 2024, 2:54 PM Mark Jacobs <
> 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > I seem to recall, but can't find anything that confirms my recollection
> > that certain HLQs such as SYS1 and PAGE have special powers as relating to
> > systems programmer type management activities. Can anyone point me to the
> > documentation if true, or tell me I'm incorrect if I am? Thanks.
> > 
> > Mark Jacobs
> > 
> > Sent from ProtonMail, Swiss-based encrypted
> > email.
> > 
> > GPG Public Key -
> > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
> > 
> > --
> > 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: Banks migrate from mainframes to AI-driven cloud tech

2024-02-09 Thread Tony Harminc
On Fri, 9 Feb 2024 at 06:35, Mark Regan <
058035dd6b20-dmarc-requ...@listserv.ua.edu> wrote:

>
> https://www.finextra.com/newsarticle/43673/banks-migrate-from-mainframes-to-ai-driven-cloud-tech


Great! Maybe an AI can hallucinate a $million into my
bank-account-in-the-cloud. And then hopefully be unable to explain itself...

Tony H.

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


Re: Banks migrate from mainframes to AI-driven cloud tech

2024-02-09 Thread roscoe5
That would improve my retirement date!
All joking aside, we’ve heard that mainframes will be going away for some time. 
And I assume many/most of us have some mainframe bias. But based on accounts, 
or transactions, or whatever … how do you see the future for mainframes?
Increasing, steady, declining, … (less simplistic answers are welcome).

Sent from [Proton Mail](https://proton.me/mail/home) for iOS

On Fri, Feb 9, 2024 at 12:31 PM, Tony Harminc <[t...@harminc.net](mailto:On 
Fri, Feb 9, 2024 at 12:31 PM, Tony Harminc < wrote:

> On Fri, 9 Feb 2024 at 06:35, Mark Regan <
> 058035dd6b20-dmarc-requ...@listserv.ua.edu> wrote:
>
>>
>> https://www.finextra.com/newsarticle/43673/banks-migrate-from-mainframes-to-ai-driven-cloud-tech
>
> Great! Maybe an AI can hallucinate a $million into my
> bank-account-in-the-cloud. And then hopefully be unable to explain itself...
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Re: HLQ of Page Dataset Names

2024-02-09 Thread Gibney, Dave
You would be better served with PAGE.&SYSNAME because you can have them 
cataloged in multiple catalogs

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Mark Jacobs
> Sent: Friday, February 9, 2024 8:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: HLQ of Page Dataset Names
> 
> [EXTERNAL EMAIL]
> 
> Yes, we're currently using the value of &SYSNAME as the HLQ for the page
> datasets. I was wondering if there's any special powers available for the HLQ 
> of
> SYS1 or PAGE.
> 
> Mark Jacobs
> 
> Sent from ProtonMail, Swiss-based encrypted email.
> 
> GPG Public Key -
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flook
> up%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com__%3B!!JmP
> EgBY0HMszNaDT!t2r_0zpttnfKKQdF472QCXfSkUBWgKXVU3L-a-
> 1YJwiUy65DMx3HtormAYh2EY3aX0F9VcNH16OYsxw3H3kVU0hI-
> iiAPmFq%24&data=05%7C02%7CGIBNEY%40WSU.EDU%7Cffd88af4468a48
> 1ba7ea08dc298fd340%7Cb52be471f7f147b4a8790c799bb53db5%7C0%7C
> 0%7C638430944905529551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C
> %7C%7C&sdata=hZw%2FWdCJeYltXnhh6UHn51SVT%2BarWsgBUwFYZu2vZv
> Y%3D&reserved=0
> 
> 
> On Friday, February 9th, 2024 at 10:16 AM, David Elliot
> <05829bddcbe4-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > Are you talking about choosing your own HLQ for page datasets?
> >
> >
> >
> > On Fri, Feb 9, 2024, 2:54 PM Mark Jacobs <
> > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > I seem to recall, but can't find anything that confirms my
> > > recollection that certain HLQs such as SYS1 and PAGE have special
> > > powers as relating to systems programmer type management activities.
> > > Can anyone point me to the documentation if true, or tell me I'm incorrect
> if I am? Thanks.
> > >
> > > Mark Jacobs
> > >
> > > Sent from ProtonMail, Swiss-based encrypted email.
> > >
> > > GPG Public Key -
> > >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fur
> > >
> ldefense.com%2Fv3%2F__https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flo
> okup
> > >
> %3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com__%3B!!JmPEg
> BY0HMs
> > > zNaDT!t2r_0zpttnfKKQdF472QCXfSkUBWgKXVU3L-a-
> 1YJwiUy65DMx3HtormAYh2EY
> > > 3aX0F9VcNH16OYsxw3H3kVU0hI-
> iiAPmFq%24&data=05%7C02%7CGIBNEY%40WSU.ED
> > >
> U%7Cffd88af4468a481ba7ea08dc298fd340%7Cb52be471f7f147b4a8790c
> 799bb53
> > >
> db5%7C0%7C0%7C638430944905538872%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4
> > >
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C
> %7C%7C
> > >
> &sdata=nlRtWaCJo9V0CfJfEJcZ%2FpEQaZC8ilrBH0p4ZQZNoKY%3D&reserved
> =0
> > >
> > > 
> > > -- 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: HLQ of Page Dataset Names

2024-02-09 Thread Mark Jacobs
For historical reasons most of our systems don't share MCATS. So I 
misremembered and there's nothing really special about specific HLQs for page 
dataset names, correct?

Mark Jacobs 

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com


On Friday, February 9th, 2024 at 1:02 PM, Gibney, Dave 
<03b5261cfd78-dmarc-requ...@listserv.ua.edu> wrote:

> You would be better served with PAGE.&SYSNAME because you can have them 
> cataloged in multiple catalogs
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On
> > Behalf Of Mark Jacobs
> > Sent: Friday, February 9, 2024 8:54 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: HLQ of Page Dataset Names
> > 
> > [EXTERNAL EMAIL]
> > 
> > Yes, we're currently using the value of &SYSNAME as the HLQ for the page
> > datasets. I was wondering if there's any special powers available for the 
> > HLQ of
> > SYS1 or PAGE.
> > 
> > Mark Jacobs
> > 
> > Sent from ProtonMail, Swiss-based encrypted email.
> > 
> > GPG Public Key -
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> > efense.com%2Fv3%2F__https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flook
> > up%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com__%3B!!JmP
> > EgBY0HMszNaDT!t2r_0zpttnfKKQdF472QCXfSkUBWgKXVU3L-a-
> > 1YJwiUy65DMx3HtormAYh2EY3aX0F9VcNH16OYsxw3H3kVU0hI-
> > iiAPmFq%24&data=05%7C02%7CGIBNEY%40WSU.EDU%7Cffd88af4468a48
> > 1ba7ea08dc298fd340%7Cb52be471f7f147b4a8790c799bb53db5%7C0%7C
> > 0%7C638430944905529551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C
> > %7C%7C&sdata=hZw%2FWdCJeYltXnhh6UHn51SVT%2BarWsgBUwFYZu2vZv
> > Y%3D&reserved=0
> > 
> > On Friday, February 9th, 2024 at 10:16 AM, David Elliot
> > 05829bddcbe4-dmarc-requ...@listserv.ua.edu wrote:
> > 
> > > Are you talking about choosing your own HLQ for page datasets?
> > > 
> > > On Fri, Feb 9, 2024, 2:54 PM Mark Jacobs <
> > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
> > > 
> > > > I seem to recall, but can't find anything that confirms my
> > > > recollection that certain HLQs such as SYS1 and PAGE have special
> > > > powers as relating to systems programmer type management activities.
> > > > Can anyone point me to the documentation if true, or tell me I'm 
> > > > incorrect
> > > > if I am? Thanks.
> > > > 
> > > > Mark Jacobs
> > > > 
> > > > Sent from ProtonMail, Swiss-based encrypted email.
> > > > 
> > > > GPG Public Key -
> > 
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fur
> > 
> > ldefense.com%2Fv3%2F__https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flo
> > okup
> > 
> > %3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com__%3B!!JmPEg
> > BY0HMs
> > 
> > > > zNaDT!t2r_0zpttnfKKQdF472QCXfSkUBWgKXVU3L-a-
> > > > 1YJwiUy65DMx3HtormAYh2EY
> > > > 3aX0F9VcNH16OYsxw3H3kVU0hI-
> > > > iiAPmFq%24&data=05%7C02%7CGIBNEY%40WSU.ED
> > 
> > U%7Cffd88af4468a481ba7ea08dc298fd340%7Cb52be471f7f147b4a8790c
> > 799bb53
> > 
> > db5%7C0%7C0%7C638430944905538872%7CUnknown%7CTWFpbGZsb3d
> > 8eyJWIjoiMC4
> > 
> > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C
> > %7C%7C
> > 
> > &sdata=nlRtWaCJo9V0CfJfEJcZ%2FpEQaZC8ilrBH0p4ZQZNoKY%3D&reserved
> > =0
> > 
> > > > 
> > > > -- 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

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


Re: HLQ of Page Dataset Names

2024-02-09 Thread Lennie Dymoke-Bradshaw
Experience shows me that this is also possible for VSAM ICSF key stores and 
VSAM RACF databases. In practice it apples to any VSAM data set I think. 
However, it may be designed for those cases noted.
I think any IDCAMS alteration of the VSAM object (e.g. ALTER NEWNAME) must be 
performed through the catalog that actually owns the object. The entries in 
non-owning catalogs can be used for access only.

Lennie
Lennie Dymoke-Bradshaw
https: //rsclweb.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Styles, Andy (CIO GS&S - Core Infrastructure & IT Operations )
Sent: 09 February 2024 16:07
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: HLQ of Page Dataset Names

Classification: Public

Certainly as far as catalog entries go, page datasets have some super powers, 
like SYS1. From experience, the catalog that the page datasets (and others) 
were originally defined in has no bearing on the catalog currently in use. From 
the DEFINE CLUSTER RECATALOG manual entry (though I see what appears to be an 
editorial side note is still included as text even in the 3.1 manual 😊).


RECATALOG
Recreates the catalog entries if valid VVDS entries are found on the primary 
VVDS volume. If they are not, the command ends.
When recataloging entries (including zFS files) with indirect volsers, the VVDS 
on the substituted volser must contain a valid NVRs or VVRs that match the 
entry name.

Catalog entries can be re-created only in the catalog specified in the VVR 
except for entries that are swap space, page space, or SYS1 data sets. Change 
this to Catalog entries can be re-created only in the catalog specified in the 
VVR except for entries that are swap space, page space, SYS1 data sets or 
single volume zFS VSAM Linear data sets with an indirect volume serial.


Andy Styles
z/Series Systems Programmer


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Elliot
Sent: Friday, February 9, 2024 3:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: HLQ of Page Dataset Names

[Some people who received this message don't often get email from 
05829bddcbe4-dmarc-requ...@listserv.ua.edu. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

*** This email is from an external source - be careful of attachments and 
links. Please report suspicious emails ***

Are you talking about choosing your own HLQ for page datasets?



On Fri, Feb 9, 2024, 2:54 PM Mark Jacobs < 
0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:

> I seem to recall, but can't find anything that confirms my 
> recollection that certain HLQs such as SYS1 and PAGE have special 
> powers as relating to systems programmer type management activities.
> Can anyone point me to the documentation if true, or tell me I'm incorrect if 
> I am? Thanks.
>
> Mark Jacobs
>
> Sent from
> [ProtonMail](https://protonmail.com/), Swiss-based encrypted email.
>
> GPG Public Key -
> https://api/.
> protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40proton
> mail.com&data=05%7C02%7CAndy.Styles%40lloydsbanking.com%7Ced61797b2ea3
> 44ef309808dc298256a3%7C3ded2960214a46ff8cf4611f125e2398%7C0%7C0%7C6384
> 30886983227735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=jlNqycjuJx9RK%2
> BxmZhesNpzxnm52rIxLW8ON9tZLtRQ%3D&reserved=0
>
> --
> 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 Lloyds Banking Group 
plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland 
no. SC95000. Telephone: 0131 225 4555.

Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. 
Registered in England and Wales no. 2065. Telephone 0207626 1500.

Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC327000. Telephone: 03457 801 801.

Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London 
EC2V 7HN. Registered in England and Wales no. 10399850.

Scottish Widows Schroder Personal Wealth Limited. Registered Office: 25 Gresham 
Street, London EC2V 7HN. Registered in England and Wales no. 11722983.

Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are 
authorised by the Prudential Regulation Authority and regulated by the 
Financial Conduct Authority and Prudential Regulation Authority.

Scottish Widows Schroder Personal Wealth Limited is authorised and regulated by 
the Financial Conduct Authority.

Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned 
subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets 
Wer

Re: XTL64E_EXTENTADDR

2024-02-09 Thread Seymour J Metz
The load module might be in the PLPA, or the load module for the RB might have 
called an external load module.

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


From: IBM Mainframe Discussion List  on behalf of 
Joseph Reichman <05812645a43c-dmarc-requ...@listserv.ua.edu>
Sent: Friday, February 9, 2024 9:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XTL64E_EXTENTADDR

Hi

What I was trying to do is that after you had helped me understand rb chain I 
was trying to get the extents of the load module to ensure that SDWAEC1 and 
SDWAEC2 fall in the range for the appropriate load module before I display the 
offsets

thanks

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter Relson
Sent: Wednesday, February 7, 2024 1:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XTL64E_EXTENTADDR

In contents supervisor speak, an extent list contains header information and 
then information about the length and address of each (module) extent (whether 
mapped by IHAXTLST or IHAXTL64.

As the name implies, XTL64E_EXTENTADDR contains the address of the extent for 
this entry. And, not surprising, there is a similar field, also appropriately 
named, that contains the length of the extent.
Applying both to XTLST and XTL64, it is relatively uncommon to need to know the 
information about the extents unless dumping the module. The entry point 
address is more common to use. Since you didn't provide any information about 
what you were intending to do with the information, I have no idea which would 
be better for you.
Peter Relsonz/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

--
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: HLQ of Page Dataset Names

2024-02-09 Thread Gibney, Dave
Even when not sharing master catalogs, using PAGE. Allows you to define them on 
a system different from the ultimate using system. I doubt any modern systems 
will ever reach the point where all PAGE space is exhausted and define from 
different system and add to stalled system would help, but such things did 
happen in the past

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Mark Jacobs
> Sent: Friday, February 9, 2024 10:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: HLQ of Page Dataset Names
> 
> [EXTERNAL EMAIL]
> 
> For historical reasons most of our systems don't share MCATS. So I
> misremembered and there's nothing really special about specific HLQs for page
> dataset names, correct?
> 
> Mark Jacobs
> 
> Sent from ProtonMail, Swiss-based encrypted email.
> 
> GPG Public Key -
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flook
> up%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com__%3B!!JmP
> EgBY0HMszNaDT!pAWO1c7mmDn_QwSQvW47zNtqLZjxXFmAjQSiQbQ3RDt1
> C5cK5ibODjyit4YTrG-
> 8oe1bcIP7jvYVdte7lA468xSU5bS2yHTD%24&data=05%7C02%7CGIBNEY%40
> WSU.EDU%7C4f71da5c5bef4c7bc66808dc299a7403%7Cb52be471f7f147b
> 4a8790c799bb53db5%7C0%7C0%7C638430990552642856%7CUnknown
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=SMKdbO8kleP4gFxXmiDfO
> K80KFMCb6duVno3%2FCuj3Sw%3D&reserved=0
> 
> 
> On Friday, February 9th, 2024 at 1:02 PM, Gibney, Dave
> <03b5261cfd78-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > You would be better served with PAGE.&SYSNAME because you can have
> > them cataloged in multiple catalogs
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On
> > > Behalf Of Mark Jacobs
> > > Sent: Friday, February 9, 2024 8:54 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: HLQ of Page Dataset Names
> > >
> > > [EXTERNAL EMAIL]
> > >
> > > Yes, we're currently using the value of &SYSNAME as the HLQ for the
> > > page datasets. I was wondering if there's any special powers
> > > available for the HLQ of
> > > SYS1 or PAGE.
> > >
> > > Mark Jacobs
> > >
> > > Sent from ProtonMail, Swiss-based encrypted email.
> > >
> > > GPG Public Key -
> > >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fur
> > >
> ldefense.com%2Fv3%2F__https%3A%2F%2Fnam12.safelinks.protection.outl
> o
> > >
> ok.com%2F%3Furl%3Dhttps*3A*2F*2Furld__%3BJSUl!!JmPEgBY0HMszNaDT
> !pAWO
> > > 1c7mmDn_QwSQvW47zNtqLZjxXFmAjQSiQbQ3RDt1C5cK5ibODjyit4YTrG-
> 8oe1bcIP7
> > >
> jvYVdte7lA468xSU5SnIrJ2R%24&data=05%7C02%7CGIBNEY%40WSU.EDU%
> 7C4f71da
> > >
> 5c5bef4c7bc66808dc299a7403%7Cb52be471f7f147b4a8790c799bb53db5
> %7C0%7C
> > >
> 0%7C638430990552652888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiL
> > >
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdat
> a=Ax%
> > >
> 2BhKaz6VuuTKnu%2BQzH9%2BNDg7prLVepqimhgyKCLBfk%3D&reserved=0
> > >
> efense.com%2Fv3%2F__https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flook
> > >
> up%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com__%3B!!JmP
> > > EgBY0HMszNaDT!t2r_0zpttnfKKQdF472QCXfSkUBWgKXVU3L-a-
> > > 1YJwiUy65DMx3HtormAYh2EY3aX0F9VcNH16OYsxw3H3kVU0hI-
> > >
> iiAPmFq%24&data=05%7C02%7CGIBNEY%40WSU.EDU%7Cffd88af4468a48
> > >
> 1ba7ea08dc298fd340%7Cb52be471f7f147b4a8790c799bb53db5%7C0%7C
> > >
> 0%7C638430944905529551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > >
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C
> > >
> %7C%7C&sdata=hZw%2FWdCJeYltXnhh6UHn51SVT%2BarWsgBUwFYZu2vZv
> > > Y%3D&reserved=0
> > >
> > > On Friday, February 9th, 2024 at 10:16 AM, David Elliot
> > > 05829bddcbe4-dmarc-requ...@listserv.ua.edu wrote:
> > >
> > > > Are you talking about choosing your own HLQ for page datasets?
> > > >
> > > > On Fri, Feb 9, 2024, 2:54 PM Mark Jacobs <
> > > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
> > > >
> > > > > I seem to recall, but can't find anything that confirms my
> > > > > recollection that certain HLQs such as SYS1 and PAGE have
> > > > > special powers as relating to systems programmer type management
> activities.
> > > > > Can anyone point me to the documentation if true, or tell me I'm
> > > > > incorrect if I am? Thanks.
> > > > >
> > > > > Mark Jacobs
> > > > >
> > > > > Sent from ProtonMail, Swiss-based encrypted email.
> > > > >
> > > > > GPG Public Key -
> > >
> > >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fur
> > >
> ldefense.com%2Fv3%2F__https%3A%2F%2Fnam12.safelinks.protection.outl
> o
> > >
> ok.com%2F%3Furl%3Dhttps*3A*2F*2Fur__%3BJSUl!!JmPEgBY0HMszNaDT!
> pAWO1c
> > > 7mmDn_QwSQvW47zNtqLZjxXFmAjQSiQbQ3RDt1C5cK5ibODjyit4YTrG-
> 8oe1bcIP7jv
> > >
> YVdte7lA468xSU5dX34g8c%24&data=05%7C02%7CGIBNEY%40WSU.EDU%7
> C4f71da5c
> > >
> 5bef4c7bc66808dc299a7403%7Cb52be471f7f147b4a8790c799bb53db5%
> 7C0%7C0%
> > >
> 7C638430990552660115%7CUnknown%7CTWFpbGZsb3d8eyJW

Re: XTL64E_EXTENTADDR

2024-02-09 Thread Tony Harminc
On Fri, 9 Feb 2024 at 13:14, Seymour J Metz  wrote:

> The load module might be in the PLPA, or the load module for the RB might
> have called an external load module.
>

Sure, but I see nothing wrong with his attempt to make the info more useful
in the case where the failure *is* within the extents of the loaded module.
Certainly if he's going to try to display an eyecatcher or a bit of the
failing code. It doesn't have to work perfectly for all cases.

Tony H.
__

> From: IBM Mainframe Discussion List  on behalf
> of Joseph Reichman <05812645a43c-dmarc-requ...@listserv.ua.edu>
> Sent: Friday, February 9, 2024 9:49 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: XTL64E_EXTENTADDR
>
> Hi
>
> What I was trying to do is that after you had helped me understand rb
> chain I was trying to get the extents of the load module to ensure that
> SDWAEC1 and SDWAEC2 fall in the range for the appropriate load module
> before I display the offsets
>

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


Re: [EXTERNAL] Re: Banks migrate from mainframes to AI-driven cloud tech

2024-02-09 Thread Pommier, Rex
Or more likely it'll hallucinate you on the wrong side of the fence (I mean, 
you're a mainframer after all, and that's bad...) and your 
bank-account-in-the-cloud funds will vanish without a trace.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Harminc
Sent: Friday, February 9, 2024 11:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Banks migrate from mainframes to AI-driven cloud tech

On Fri, 9 Feb 2024 at 06:35, Mark Regan < 
058035dd6b20-dmarc-requ...@listserv.ua.edu> wrote:

>
> https://urldefense.com/v3/__https://www.finextra.com/newsarticle/43673
> /banks-migrate-from-mainframes-to-ai-driven-cloud-tech__;!!KjMRP1Ixj6e
> LE0Fj!tLr6t9f_YDLnxiyLJH-6ow1HEjTZWJ5z2DnmHImDrhr9_JpV0t51xKyqwrHd7jPF
> 8URmbfzgR31WAtMe$


Great! Maybe an AI can hallucinate a $million into my 
bank-account-in-the-cloud. And then hopefully be unable to explain itself...

Tony H.

--
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: [EXTERNAL] Re: Banks migrate from mainframes to AI-driven cloud tech

2024-02-09 Thread Dave Beagle
As IBM stock hits new highs.


Sent from Yahoo Mail for iPhone


On Friday, February 9, 2024, 1:40 PM, Pommier, Rex  
wrote:

Or more likely it'll hallucinate you on the wrong side of the fence (I mean, 
you're a mainframer after all, and that's bad...) and your 
bank-account-in-the-cloud funds will vanish without a trace.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Harminc
Sent: Friday, February 9, 2024 11:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Banks migrate from mainframes to AI-driven cloud tech

On Fri, 9 Feb 2024 at 06:35, Mark Regan < 
058035dd6b20-dmarc-requ...@listserv.ua.edu> wrote:

>
> https://urldefense.com/v3/__https://www.finextra.com/newsarticle/43673
> /banks-migrate-from-mainframes-to-ai-driven-cloud-tech__;!!KjMRP1Ixj6e
> LE0Fj!tLr6t9f_YDLnxiyLJH-6ow1HEjTZWJ5z2DnmHImDrhr9_JpV0t51xKyqwrHd7jPF
> 8URmbfzgR31WAtMe$


Great! Maybe an AI can hallucinate a $million into my 
bank-account-in-the-cloud. And then hopefully be unable to explain itself...

Tony H.

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




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


Re: Banks migrate from mainframes to AI-driven cloud tech

2024-02-09 Thread Dave Beagle
Increasing. More transactions on the mainframe this year than last, more next 
year than this year. Continuing for decades.


Sent from Yahoo Mail for iPhone


On Friday, February 9, 2024, 12:46 PM, roscoe5 
<056b62686b81-dmarc-requ...@listserv.ua.edu> wrote:

That would improve my retirement date!
All joking aside, we’ve heard that mainframes will be going away for some time. 
And I assume many/most of us have some mainframe bias. But based on accounts, 
or transactions, or whatever … how do you see the future for mainframes?
Increasing, steady, declining, … (less simplistic answers are welcome).

Sent from [Proton Mail](https://proton.me/mail/home) for iOS

On Fri, Feb 9, 2024 at 12:31 PM, Tony Harminc <[t...@harminc.net](mailto:On 
Fri, Feb 9, 2024 at 12:31 PM, Tony Harminc < wrote:

> On Fri, 9 Feb 2024 at 06:35, Mark Regan <
> 058035dd6b20-dmarc-requ...@listserv.ua.edu> wrote:
>
>>
>> https://www.finextra.com/newsarticle/43673/banks-migrate-from-mainframes-to-ai-driven-cloud-tech
>
> Great! Maybe an AI can hallucinate a $million into my
> bank-account-in-the-cloud. And then hopefully be unable to explain itself...
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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




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


Re: Reading a scratch tape)

2024-02-09 Thread Gary Weinhold
>Rex wrote:
>Actually, it does make sense (at least to me) to have this threshold set.  
>We've gone back more than once to rescue a developer or support person who 
>inadvertently >scratched a tape the day before and we were able to recover it 
>for them by using this "expired but not really" feature.  It is really no 
>different from old physical tapes, >where the data on a scratch tape wasn't 
>really gone until the tape was physically written over.  In those days, one 
>could jump through hoops (and security) to get the >contents brought back.  
>This simply maintains that capability.  Without the expire hold, as soon as 
>the tape is scratch, the data is gone.

Back in the 70s,  payroll was run in-house at the place I worked.  Every 2 
weeks the head of payroll would bring in a removable disk pack and stay in the 
computer room until the checks and reports were printed and then took 
everything back with him.  There was a back up to reel tape.  A tape label with 
the dataset name was printed and stuck on the reel as it was removed from the 
drive and stored in the computer room until expiration.  The operators knew 
these tapes would only be used by payroll.
Each tape had its serial number prominently displayed on its perimeter case.   
When a tape expired, the tape label was removed and it was hung on a scratch 
rack.
 A co-worker waited until the payroll backup tape expired and ran a utility to 
print the contents, calling for the expired tape by serial number with BLP.  In 
order to minimize his chances of detection by nosy operators, who would stop 
the printer and adjust the paper feed behind the printer if they thought 
something interesting was being printed, he printed it in hex.
I got involved because he couldn't read hex.  So, taking this as an educational 
opportunity, I showed him how to use the green card to interpret the name field 
and find packed decimal fields using my record as an example.  He left for 
greener pastures soon after.



F

Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone:+1.613.523.5500 x216
Email: weinh...@dkl.com
Visit us online at www.DKL.com
E-mail Notification: The information contained in this email and any 
attachments is confidential and may be subject to copyright or other 
intellectual property protection. If you are not the intended recipient, you 
are not authorized to use or disclose this information, and we request that you 
notify us by reply mail or telephone and delete the original message from your 
mail system.



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


Re: Banks migrate from mainframes to AI-driven cloud tech

2024-02-09 Thread Bobbie Jo Justice
More companies in their 20th year of their three year plan to get off the 
mainframe?

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


Re: [EXTERNAL] Re: Reading a scratch tape

2024-02-09 Thread Paul Gilmartin
On Thu, 8 Feb 2024 22:41:03 +, Pommier, Rex wrote:
>
>Actually, it does make sense (at least to me) to have this threshold set.  
>We've gone back more than once to rescue a developer or support person who 
>inadvertently scratched a tape the day before and we were able to recover it 
>for them by using this "expired but not really" feature...>
>
I believe PDS86 has a similar ability to recover deleted PDS members.

Does this work for PDSE?  I suspect it's harder.  Is that used as an argument 
against
migrating from PDS to PDSE?

That's what generations are for.

-- 
gil

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


Re: Banks migrate from mainframes to AI-driven cloud tech

2024-02-09 Thread Phil Smith III
roscoe5 asked:

>how do you see the future for mainframes?

>Increasing, steady, declining, .

 

[Editorializing ahead!]

As usual, "It depends". There are fewer mainframe shops than there were, but 
more usage. 

 

A simple example: consider payment processors, many (not all) of whom have at 
least some IBM zSystems. Recent consolidation there (multi-billion-dollar 
deals): FIS bought Worldpay; Fiserv bought First Data; Global Payments bought 
Heartland and TSYS. Seven companies are now three. So there's your "fewer 
customers". Meanwhile, of course, transaction volumes at these and other 
committed companies are still growing. So there's your "more usage".

 

What I assume will happen over time is that along with continued consolidation, 
some shops will move off because some bright young spark is convinced it will 
be better. Doesn't mean they're right, but that doesn't mean it won't happen. 
Even when that doesn't happen, various other evolution will chip away at some 
usage when it becomes (or, again, SEEMS to become) wiser to move some 
processing off. And essentially nobody is moving new processing TO the 
mainframe, because reasons.

 

At the same time, while the smarter companies get it and see no reason to move, 
there aren't a significant number of new mainframe shops. A few LinuxONEs, but 
zero new z/OS or z/VM or z/VSE or z/TPF shops. I don't see any way this trend 
will reverse, though by the same token I don't see the mainframe going away 
anytime soon. It will just become more and more of a niche market of large 
systems-sort of strange, "big niche"! The aging of the mainframe community 
isn't help, of course.

 

In some ways it looks (at the right distance) like a return to the early days 
of computing, where big iron shops were few but serious. Of course then it was 
big iron vs. nothing; now it's big iron vs. racks, cloud, etc.

 

Maybe AI will reverse this trend, though I personally don't see it. Like many 
current Internet services, AI usage looks like it will largely comprise two 
things: building the LLM (which is expensive but not real-time and can retry on 
failure, so might as well use cheap MIPS) and then querying/using the LLM 
(which is real-time but not critical, so might as well use cheap MIPS). Plus 
there's been a whole shift from "computers should work" to "computers should 
*mostly* work". When your Google search fails or your Instagram page doesn't 
load, you shrug and try again. When your credit card transaction doesn't go 
through, neither you nor the merchant just shrug. But you're starting to-when 
it's a website and the transaction fails, you scowl but try it again, and if it 
works that time, you forget about it. We're being conditioned to accept 
mediocrity, and AI in its current incarnation doesn't appear to be ready to 
reverse that. It's depressing.

 

Meanwhile, a colleague happened to send me this:
https://www.itpro.com/cloud/cloud-computing/cloud-computing-or-mainframe-why-the-pendulum-might-be-swinging-back-in-the-age-of-hybrid-strategies-and-generative-ai
which is a bit more cheerful, albeit more "the leak is slowing" than "things 
are improving".


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


Re: Banks migrate from mainframes to AI-driven cloud tech

2024-02-09 Thread Dave Beagle
Large amounts of data, including AI, will require processing power (and 
security) unlike anything DP has seen. Perfect for the mainframe. And, there 
ARE new mainframe shops. 


Sent from Yahoo Mail for iPhone


On Friday, February 9, 2024, 7:11 PM, Phil Smith III  wrote:

roscoe5 asked:

>how do you see the future for mainframes?

>Increasing, steady, declining, .

 

[Editorializing ahead!]

As usual, "It depends". There are fewer mainframe shops than there were, but 
more usage. 

 

A simple example: consider payment processors, many (not all) of whom have at 
least some IBM zSystems. Recent consolidation there (multi-billion-dollar 
deals): FIS bought Worldpay; Fiserv bought First Data; Global Payments bought 
Heartland and TSYS. Seven companies are now three. So there's your "fewer 
customers". Meanwhile, of course, transaction volumes at these and other 
committed companies are still growing. So there's your "more usage".

 

What I assume will happen over time is that along with continued consolidation, 
some shops will move off because some bright young spark is convinced it will 
be better. Doesn't mean they're right, but that doesn't mean it won't happen. 
Even when that doesn't happen, various other evolution will chip away at some 
usage when it becomes (or, again, SEEMS to become) wiser to move some 
processing off. And essentially nobody is moving new processing TO the 
mainframe, because reasons.

 

At the same time, while the smarter companies get it and see no reason to move, 
there aren't a significant number of new mainframe shops. A few LinuxONEs, but 
zero new z/OS or z/VM or z/VSE or z/TPF shops. I don't see any way this trend 
will reverse, though by the same token I don't see the mainframe going away 
anytime soon. It will just become more and more of a niche market of large 
systems-sort of strange, "big niche"! The aging of the mainframe community 
isn't help, of course.

 

In some ways it looks (at the right distance) like a return to the early days 
of computing, where big iron shops were few but serious. Of course then it was 
big iron vs. nothing; now it's big iron vs. racks, cloud, etc.

 

Maybe AI will reverse this trend, though I personally don't see it. Like many 
current Internet services, AI usage looks like it will largely comprise two 
things: building the LLM (which is expensive but not real-time and can retry on 
failure, so might as well use cheap MIPS) and then querying/using the LLM 
(which is real-time but not critical, so might as well use cheap MIPS). Plus 
there's been a whole shift from "computers should work" to "computers should 
*mostly* work". When your Google search fails or your Instagram page doesn't 
load, you shrug and try again. When your credit card transaction doesn't go 
through, neither you nor the merchant just shrug. But you're starting to-when 
it's a website and the transaction fails, you scowl but try it again, and if it 
works that time, you forget about it. We're being conditioned to accept 
mediocrity, and AI in its current incarnation doesn't appear to be ready to 
reverse that. It's depressing.

 

Meanwhile, a colleague happened to send me this:
https://www.itpro.com/cloud/cloud-computing/cloud-computing-or-mainframe-why-the-pendulum-might-be-swinging-back-in-the-age-of-hybrid-strategies-and-generative-ai
which is a bit more cheerful, albeit more "the leak is slowing" than "things 
are improving".


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