Re: Risk/Reward ASVT in 31 bit storage

2023-09-22 Thread Mark Zelden
On Fri, 22 Sep 2023 16:10:37 -0500, Mark Zelden  wrote:

>On Fri, 22 Sep 2023 19:50:43 +, Mark Jacobs  
>wrote:
>
>>So nothing more than that. IMHO it doesn't seem too worthwhile in most 
>>environments. Thanks however.
>>
>>Mark Jacobs 
>>
>
>I agree.  I never did it except in sandbox environments and usually wait a 
>couple of 
>releases for changing things like that, but never did it in production.  The 
>problem is 
>homegrown code that may be floating around in production environments that
>you don't know about.  I'm often surprised about the kinds of things I discover
>running as part of batch jobs when some need to research a problem
>comes up.
>

I was going to site my own ASIDLIST program on my web site / CBT file 434,
but I just looked and I forgot I updated it in 2016 to support ASVT above the
line. :)   So that is indeed a long time that this option has been available
and all software should support it by now.   The REXX version needed no
changes of course (ASIDLRX).  

Off subject:  I would really like to (also) extend my appreciation to the list
owner - Darren Evans-Young - for cracking down on off subject posts and
all the nostalgia posts etc.  I have actually had time this week to follow the
list from the web archives and keep up with posts with my super busy
schedule.
Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html

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


Re: Risk/Reward ASVT in 31 bit storage

2023-09-22 Thread Mark Zelden
On Fri, 22 Sep 2023 19:50:43 +, Mark Jacobs  
wrote:

>So nothing more than that. IMHO it doesn't seem too worthwhile in most 
>environments. Thanks however.
>
>Mark Jacobs 
>

I agree.  I never did it except in sandbox environments and usually wait a 
couple of 
releases for changing things like that, but never did it in production.  The 
problem is 
homegrown code that may be floating around in production environments that
you don't know about.  I'm often surprised about the kinds of things I discover
running as part of batch jobs when some need to research a problem
comes up.

You can also move the LCCA and PCCA above the line via CBLOC in DIAGxx. 
That was introduced in z/OS 1.9 and the default in z/OS 1.12, so you should
be running with it.  ASVT option was in z/OS 2.1 and still isn't above by
default (maybe z/OS 3.1? I haven't looked).  

All my sandbox LPARs have this coded and I'm sure system software is all
fine since z/OS 2.3.  I think I added ASVT even in z/OS 2.1 in my sandboxes
after all software had z/OS 2.1 maintenance or versions running. 

CBLOC VIRTUAL31(IHALCCA,IHAPCCA,IHAASVT) 

Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html

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


Re: Risk/Reward ASVT in 31 bit storage

2023-09-22 Thread Mark Jacobs
So nothing more than that. IMHO it doesn't seem too worthwhile in most 
environments. Thanks however.

Mark Jacobs 

Sent from ProtonMail, Swiss-based encrypted email.

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


--- Original Message ---
On Friday, September 22nd, 2023 at 3:45 PM, Mark Zelden  
wrote:


> On Fri, 22 Sep 2023 16:30:31 +, Mark Jacobs markjac...@protonmail.com 
> wrote:
> 
> > I know what the risks are in moving the ASVT into 31 bit storage, but I 
> > don't see any benefits. Can someone enlighten me?
> > 
> > Mark Jacobs
> 
> 
> Isn't it obvious? Slightly more 24-bit storage for programs needing below the 
> line private.
> And I do mean slightly. It is about 4K per 1000 entries. I guess you would 
> add up
> MAXUSER and RSVNONR to know what you are using now. Each ASVT entry is
> 4 bytes in SQA <16M, so less SQA means more private.
> 
> Best Regards,
> 
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
> ITIL v3 Foundation Certified
> mailto:m...@mzelden.com
> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
> 
> --
> 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: Risk/Reward ASVT in 31 bit storage

2023-09-22 Thread Mark Zelden
On Fri, 22 Sep 2023 16:30:31 +, Mark Jacobs  
wrote:

>I know what the risks are in moving the ASVT into 31 bit storage, but I don't 
>see any benefits. Can someone enlighten me?
>
>Mark Jacobs
>

Isn't it obvious?  Slightly more 24-bit storage for programs needing below the 
line private.  
And I do mean slightly.   It is about 4K per 1000 entries.  I guess you would 
add up
MAXUSER and RSVNONR to know what you are using now.  Each ASVT entry is
4 bytes in SQA <16M, so less SQA means more private.  

Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html

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


Risk/Reward ASVT in 31 bit storage

2023-09-22 Thread Mark Jacobs
I know what the risks are in moving the ASVT into 31 bit storage, but I don't 
see any benefits. Can someone enlighten me?

Mark Jacobs

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

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

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