Re: VolCat - Reallocate ?

[Brian Westerman]

You should stop all tape processing, (RMM or CA-1, or whatever you have), 
because while the VOLCAT is not available no changes will work correctly.
Actually IBM says:

Quiesce tape library management with console command V 
SMS,LIBRARY(libname),ALL,OFFLINE for each library sharing the volume catalog to 
be moved. 



Even if your volcat is really-really big, it should take no longer than a 
minute or two.  

Don't skip steps in the example.

For a site that volsers all start with "V" you will probably have to do both.  
If you have multiple Volser ranges you might have more.

SYS1.VOLCAT.VGENERAL
SYS1.VOLCAT.VV   (this is called a specific volcat,  hlq.VOLCAT.Vx ('x' 
being first character of a volser))

Library records reside in the general VOLCAT
Volume records may reside in either the general or specific VOLCAT – specific 
VOLCAT searched first.

If one is created with imbed and replicate, the other will likely be as well.

You can run the diagnose and examine ahead of time and get them out of the way 
(and to make sure you don't have anything to fix).

When you export the catalog(s), do it twice as in the suggestion within step 3 
because you can never have too many backups.  Don't worry about the info apars 
for making it faster, because unless you have millions of volumes the time 
saved will not really be measurable 

You will need to skip step 4 because you are changing the attributes of your 
new catalog. 

There are some special directions if you have multiple master catalogs that you 
can skip if you have just one master catalog. 

Incidentally if you ever want to just move the volcat and not change anything, 
IBM has another page at 
https://www.ibm.com/support/pages/how-move-volcat-new-volume that covers it.

Let me know if you need help building the JCL,  It seems like a lot of work, 
but it's actually quite straightforward if you read the directions.

Brian

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

Re: sdwagrsv not equal rbgrsave

[Joseph Reichman]

Tom 

You correct chasing all the way back I got to the next RB and the regs were 
there 

Thanks 

> On Jan 16, 2024, at 2:50 PM, Joseph Reichman  wrote:
> 
> 
> All 
> 
> I can say logic would dictate that If I matched the PSW ie SDWAEC1 == RBOPSW 
> 
> The error registers sdwagrsv should then match 
> 
>>> On Jan 16, 2024, at 1:46 PM, Binyamin Dissen  
>>> wrote:
>>> 
>> On Tue, 16 Jan 2024 17:33:39 + Joseph Reichman 
>> wrote:
>> 
>> :>I know I can use the registers in the SDWA but the SDWA gets it from a 
>> known control block like the RB or linkage stack
>> 
>> While it may get it from a known location, it does not follow that the "known
>> location" is static.
>> 
>> --
>> Binyamin Dissen 
>> http://www.dissensoftware.com
>> 
>> Director, Dissen Software, Bar & Grill - Israel
>> 
>> --
>> 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: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

[Phil Smith III]

Paul Gilmartin wrote:
>I believe otherwise. I know of a case where a vendor allowed a product
>to escape to the field containing a tester's back door, and another
>related to II14489. Either could be exploited with no brute force,
>merely knowledge of the existence and nature of the defect. In the
>case of the latter, the vendor chose to obscure the details very long
>term to protect customers who might not have installed the fix.
>"That's security by obscurity."

But that's still the same thing, just smaller: IF they knew about it, then they 
could exploit it. It's just a matter of degree. Similarly, OCO makes it harder 
to find the way around, say, a CPUID or license key. 

>But protecting passwords is a valid use of "That's security by
>obscurity." A password is not a pervasive defect as those other cases
>are.

"protecting passwords" in what context? I'm sure your point is valid but it's 
escaping me!


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

Re: Netview, REXX and assembler interfaces for variable access

[Schmitt, Michael]

For some reason Microsoft Defender on our Exchange server has started 
quarantining a high percentage of messages from this listserv as phishing 
attempts. At first I thought it was just the messages talking about s.s.h. 
(periods added for this reason), but even messages like this one below were 
caught.

I don't know what is triggering it, unless it is the footer.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Willy Jensen
Sent: Tuesday, January 9, 2024 10:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Netview, REXX and assembler interfaces for variable access

Turns out the problem is with IRXSAY, I can read and write variables using 
IRXEXCOM. But IRXSAY returns with return code 28 'A language processor 
environment could not be located'. Unfortunately I was not checking for IRXSAY 
return codes, as IRXSAY just works, well at least in TSO it does. So now to 
find an alternative to that.

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

[Jeremy Nicoll]

On Tue, 16 Jan 2024, at 14:08, Parry, Gary (PERATON) wrote:
> Also, Teams popup 
> notifications show in the far lower right corner of the display.  That 
> took some getting used to..

If the popup notifications are able to be moved once they pop up,
you could probably use something like AutoHotKey (which is 
much more versatile than its name suggests) to sit waiting for 
such a popup to happen, and when it does, move it to 
somewhere more central, or maybe to make them 
appear in the middle of your currently-focussed window.

See: https://www.autohotkey.com/

-- 
Jeremy Nicoll - my opinions are my own.

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

Re: sdwagrsv not equal rbgrsave

[Joseph Reichman]

Thanks

I understand what you are saying
In order to go forward then when I get to RB == TCB

I should then pick up TCBRBP should of done that
Thank you

Get Outlook for iOS

From: IBM Mainframe Discussion List  on behalf of Tom 
Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, January 16, 2024 2:50:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: sdwagrsv not equal rbgrsave

You are doing a poor job of responding to questions and providing
details.

When a program running in TCB mode is interrupted, the registers are
stored in the TCB and the PSW is stored in the RB. If a new RB is
created, for example because of SVC 13, the registers from the TCB
are copied into the new RB.

Chaining back from the abending RB (via RBLINK) will not provide useful
information about the abend. Did you look in the next RB?

--
Tom Marchant

On Tue, 16 Jan 2024 09:43:16 -0500, Joseph Reichman  wrote:

>I was running under TESTAUTH
>
>I produced an abend in a space switching pc stacking routine
>
>SDWAEC2 matched up with the linkage stack PSW
>
>SDWAEC1 matched up with RBOPSW of SDWARBAD sdwagrsv didn’t match the rb regs
>Chaining back RBLINK equal TCB so I was at the end of the RBs
>
>> On Jan 16, 2024, at 9:39 AM, Seymour J Metz  wrote:
>>
>> Was it SRB or TCB? Which RBs did you look at.
>>
>> Providing more details in your questions would enable better answers. If you 
>> have a situation where you're not allowed to post details, it's best to say 
>> so up front.
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>> עַם יִשְׂרָאֵל חַי
>> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> Joseph Reichman 
>> Sent: Tuesday, January 16, 2024 9:33 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: sdwagrsv not equal rbgrsave
>>
>> Seymour in my case sdawgrsv wasn’t in either TCB regs or rb regs
>>
>> Im sure Peter knows where they are located if they are in some  internal IBM 
>> controls block ( in which case he can not or it would be useless to tell me)
>>
>> But I just don’t think that’s the case
>>
>>> On Jan 16, 2024, at 9:29 AM, Seymour J Metz  wrote:
>>>
>>> Logic does not dictate where to store registers; there are at least two 
>>> equally logical locations. In a z/OS TCB environment, the RB holds the 
>>> caller's registers and the TCB holds the current registers with a few 
>>> exceptions. This is documented.
>>>
>>> For SRB mode I'm not sure how much is GUPI.
>>>
>>> --
>>> Shmuel (Seymour J.) Metz
>>> http://mason.gmu.edu/~smetz3
>>> עַם יִשְׂרָאֵל חַי
>>> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>>>
>>> 
>>> From: IBM Mainframe Discussion List  on behalf of 
>>> Joseph Reichman 
>>> Sent: Tuesday, January 16, 2024 8:34 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: sdwagrsv not equal rbgrsave
>>>
>>> Peter
>>>
>>> Its my understanding that everything in the SDWA is copied from another 
>>> control block somewhere in the case of SDWAEC2 you helped me locate that in 
>>> the linkage stack.
>>>
>>> For SDWAEC1 I was able to locate that in the RBOPSW of SDWARBAD
>>>
>>> My logic tells me that PSW and REGS go together but when I tried to match 
>>> up SDWAGRSV to TBGRSAVE it didn’t.
>>>
>>> I think tried chaining back via RBLINK, but I got the TCB address meaning 
>>> it was the end of the chain.
>>>
>>> Grasping at straws I looked at TCBREGS, but it was there either.
>>>
>>> If the error regs SDWAGRSV are in some private IBM control block I can 
>>> understand that you cannot, or it would be useless to tell me.
>>>
>>> But my gut tells me it somewhere I can access it.
>>>
>>>
>>> thanks
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List  On Behalf Of 
>>> Peter Relson
>>> Sent: Tuesday, January 16, 2024 5:09 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: sdwagrsv not equal rbgrsave
>>>
>>> Simple experimentation will show what you need to know about what is saved 
>>> where.
>>> For example, suppose your mainline links to another routine.You mainline's 
>>> RB and the LINK target's RB can be examined.
>>> Or suppose your mainline has an ESTAE and abends.You can examine the 
>>> mainline's RB, then the (next newer) RTM SVRB, then the (next newer) ESTAE 
>>> routine's PRB.
>>> If you were trying to think about why it does what you will figure out that 
>>> it does, you'd realize that the regs that the SVC interrupt handler 
>>> processing wants to use have to be saved really quickly but the PSW is 
>>> already captured (in SVC Old PSW).
>>>
>>> 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 

Re: sdwagrsv not equal rbgrsave

[Tom Marchant]

You are doing a poor job of responding to questions and providing 
details.

When a program running in TCB mode is interrupted, the registers are 
stored in the TCB and the PSW is stored in the RB. If a new RB is 
created, for example because of SVC 13, the registers from the TCB 
are copied into the new RB.

Chaining back from the abending RB (via RBLINK) will not provide useful 
information about the abend. Did you look in the next RB?

-- 
Tom Marchant

On Tue, 16 Jan 2024 09:43:16 -0500, Joseph Reichman  wrote:

>I was running under TESTAUTH 
>
>I produced an abend in a space switching pc stacking routine 
>
>SDWAEC2 matched up with the linkage stack PSW 
>
>SDWAEC1 matched up with RBOPSW of SDWARBAD sdwagrsv didn’t match the rb regs 
>Chaining back RBLINK equal TCB so I was at the end of the RBs
>
>> On Jan 16, 2024, at 9:39 AM, Seymour J Metz  wrote:
>> 
>> Was it SRB or TCB? Which RBs did you look at.
>> 
>> Providing more details in your questions would enable better answers. If you 
>> have a situation where you're not allowed to post details, it's best to say 
>> so up front.
>> 
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>> עַם יִשְׂרָאֵל חַי
>> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>> 
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> Joseph Reichman 
>> Sent: Tuesday, January 16, 2024 9:33 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: sdwagrsv not equal rbgrsave
>> 
>> Seymour in my case sdawgrsv wasn’t in either TCB regs or rb regs
>> 
>> Im sure Peter knows where they are located if they are in some  internal IBM 
>> controls block ( in which case he can not or it would be useless to tell me)
>> 
>> But I just don’t think that’s the case
>> 
>>> On Jan 16, 2024, at 9:29 AM, Seymour J Metz  wrote:
>>> 
>>> Logic does not dictate where to store registers; there are at least two 
>>> equally logical locations. In a z/OS TCB environment, the RB holds the 
>>> caller's registers and the TCB holds the current registers with a few 
>>> exceptions. This is documented.
>>> 
>>> For SRB mode I'm not sure how much is GUPI.
>>> 
>>> --
>>> Shmuel (Seymour J.) Metz
>>> http://mason.gmu.edu/~smetz3
>>> עַם יִשְׂרָאֵל חַי
>>> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>>> 
>>> 
>>> From: IBM Mainframe Discussion List  on behalf of 
>>> Joseph Reichman 
>>> Sent: Tuesday, January 16, 2024 8:34 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: sdwagrsv not equal rbgrsave
>>> 
>>> Peter
>>> 
>>> Its my understanding that everything in the SDWA is copied from another 
>>> control block somewhere in the case of SDWAEC2 you helped me locate that in 
>>> the linkage stack.
>>> 
>>> For SDWAEC1 I was able to locate that in the RBOPSW of SDWARBAD
>>> 
>>> My logic tells me that PSW and REGS go together but when I tried to match 
>>> up SDWAGRSV to TBGRSAVE it didn’t.
>>> 
>>> I think tried chaining back via RBLINK, but I got the TCB address meaning 
>>> it was the end of the chain.
>>> 
>>> Grasping at straws I looked at TCBREGS, but it was there either.
>>> 
>>> If the error regs SDWAGRSV are in some private IBM control block I can 
>>> understand that you cannot, or it would be useless to tell me.
>>> 
>>> But my gut tells me it somewhere I can access it.
>>> 
>>> 
>>> thanks
>>> 
>>> -Original Message-
>>> From: IBM Mainframe Discussion List  On Behalf Of 
>>> Peter Relson
>>> Sent: Tuesday, January 16, 2024 5:09 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: sdwagrsv not equal rbgrsave
>>> 
>>> Simple experimentation will show what you need to know about what is saved 
>>> where.
>>> For example, suppose your mainline links to another routine.You mainline's 
>>> RB and the LINK target's RB can be examined.
>>> Or suppose your mainline has an ESTAE and abends.You can examine the 
>>> mainline's RB, then the (next newer) RTM SVRB, then the (next newer) ESTAE 
>>> routine's PRB.
>>> If you were trying to think about why it does what you will figure out that 
>>> it does, you'd realize that the regs that the SVC interrupt handler 
>>> processing wants to use have to be saved really quickly but the PSW is 
>>> already captured (in SVC Old PSW).
>>> 
>>> 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

Re: HEALTH CHECKER (USS_FILESYS_CONFIG)

[Peter Ten Eyck]

Thanks for the posts. The fix was a RACF change to permit the id that Health 
Checker is running under access to BPX.SUPERUSER in the FACILITY class. The USS 
health checks are now running.

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

Re: sdwagrsv not equal rbgrsave

[Binyamin Dissen]

On Tue, 16 Jan 2024 17:33:39 + Joseph Reichman 
wrote:

:>I know I can use the registers in the SDWA but the SDWA gets it from a known 
control block like the RB or linkage stack

While it may get it from a known location, it does not follow that the "known
location" is static.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

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

Re: VolCat - Reallocate ?

[Allan Staller]

Classification: Confidential

You might need to add RMM to the tasks to be started/stopped. Not sure if CA-1 
uses the volcat as well.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Tuesday, January 16, 2024 11:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: VolCat - Reallocate ?

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

Hi,
  So I need to reallocate my VOLCAT, due to IMBED and REPLICATE present.

So my question is what steps to perform? Like This maybe?

Stop OAM?
Export VOLCAT?
Delete VOLCAT
ALLOCATE new VOLCAT.
IMPORT from Exported copy?
Start OAM?

Is this right, anyone have JCL example of EXP/IMPORT of a volcat?

Or anything I am missing?
Thanks

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com



 [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] 

This email message and any attachments may contain confidential, proprietary or 
non-public information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


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

Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

[Paul Gilmartin]

On Tue, 16 Jan 2024 12:31:36 -0500, Phil Smith III wrote:

>...
>For example, 256-bit AES can be broken by brute force-if you have until the 
>end of time. (And if you'll know it when you see it, another issue.) But that 
>"until the end of time" means you can use it to outrun the bear.
>
>When people say "That's security by obscurity", they really mean "That's weak 
>security because the barriers aren't high enough". That's all. It's not a big 
>revelation.
> 
I believe otherwise.  I know of a case where a vendor allowed a product to
escape to the field containing a tester's back door, and another related
to II14489.  Either could be exploited with no brute force, merely knowledge
of the existence and nature of the defect.  In the case of the latter, the
vendor chose to obscure the details very long term to protect customers
who might not have installed the fix.  "That's security by obscurity."

But protecting passwords is a valid use of "That's security by obscurity."
A password is not a pervasive defect as those other cases are.

-- 
gil

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

Re: VolCat - Reallocate ?

[Mike Schwab]

https://www.ibm.com/support/pages/apar/II13354

Used this about 2015-6.

On Tue, Jan 16, 2024 at 11:30 AM Shaffer, Terri <
017d5f778222-dmarc-requ...@listserv.ua.edu> wrote:

> Hi,
>   So I need to reallocate my VOLCAT, due to IMBED and REPLICATE present.
>
> So my question is what steps to perform? Like This maybe?
>
> Stop OAM?
> Export VOLCAT?
> Delete VOLCAT
> ALLOCATE new VOLCAT.
> IMPORT from Exported copy?
> Start OAM?
>
> Is this right, anyone have JCL example of EXP/IMPORT of a volcat?
>
> Or anything I am missing?
> Thanks
>
> Ms Terri E Shaffer
> Senior Systems Engineer,
> z/OS Support:
> ACIWorldwide – Telecommuter
> H(412-766-2697) C(412-519-2592)
> terri.shaf...@aciworldwide.com
>
>
> 
>  [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] <
> http://www.aciworldwide.com>
> This email message and any attachments may contain confidential,
> proprietary or non-public information. The information is intended solely
> for the designated recipient(s). If an addressing or transmission error has
> misdirected this email, please notify the sender immediately and destroy
> this email. Any review, dissemination, use or reliance upon this
> information by unintended recipients is prohibited. Any opinions expressed
> in this email are those of the author personally.
>
> --
> 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: sdwagrsv not equal rbgrsave

[Joseph Reichman]

I know I can use the registers in the SDWA but the SDWA gets it from a known 
control block like the RB or linkage stack

Get Outlook for iOS

From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Tuesday, January 16, 2024 12:19:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: sdwagrsv not equal rbgrsave

So after the ABEND but before the dump there was further activity, changing the 
registers in the dump. Where does your PC routine store registers?

I'm pretty sure that in your scenario you need to use the values in the SDWA, 
but perhaps Peter can clarify.

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


From: IBM Mainframe Discussion List  on behalf of 
Joseph Reichman 
Sent: Tuesday, January 16, 2024 9:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: sdwagrsv not equal rbgrsave

I was running under TESTAUTH

I produced an abend in a space switching pc stacking routine

SDWAEC2 matched up with the linkage stack PSW

SDWAEC1 matched up with RBOPSW of SDWARBAD sdwagrsv didn’t match the rb regs
Chaining back RBLINK equal TCB so I was at the end of the RBs

> On Jan 16, 2024, at 9:39 AM, Seymour J Metz  wrote:
>
> Was it SRB or TCB? Which RBs did you look at.
>
> Providing more details in your questions would enable better answers. If you 
> have a situation where you're not allowed to post details, it's best to say 
> so up front.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Joseph Reichman 
> Sent: Tuesday, January 16, 2024 9:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: sdwagrsv not equal rbgrsave
>
> Seymour in my case sdawgrsv wasn’t in either TCB regs or rb regs
>
> Im sure Peter knows where they are located if they are in some  internal IBM 
> controls block ( in which case he can not or it would be useless to tell me)
>
> But I just don’t think that’s the case
>
>> On Jan 16, 2024, at 9:29 AM, Seymour J Metz  wrote:
>>
>> Logic does not dictate where to store registers; there are at least two 
>> equally logical locations. In a z/OS TCB environment, the RB holds the 
>> caller's registers and the TCB holds the current registers with a few 
>> exceptions. This is documented.
>>
>> For SRB mode I'm not sure how much is GUPI.
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>> עַם יִשְׂרָאֵל חַי
>> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> Joseph Reichman 
>> Sent: Tuesday, January 16, 2024 8:34 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: sdwagrsv not equal rbgrsave
>>
>> Peter
>>
>> Its my understanding that everything in the SDWA is copied from another 
>> control block somewhere in the case of SDWAEC2 you helped me locate that in 
>> the linkage stack.
>>
>> For SDWAEC1 I was able to locate that in the RBOPSW of SDWARBAD
>>
>> My logic tells me that PSW and REGS go together but when I tried to match up 
>> SDWAGRSV to TBGRSAVE it didn’t.
>>
>> I think tried chaining back via RBLINK, but I got the TCB address meaning it 
>> was the end of the chain.
>>
>> Grasping at straws I looked at TCBREGS, but it was there either.
>>
>> If the error regs SDWAGRSV are in some private IBM control block I can 
>> understand that you cannot, or it would be useless to tell me.
>>
>> But my gut tells me it somewhere I can access it.
>>
>>
>> thanks
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf Of 
>> Peter Relson
>> Sent: Tuesday, January 16, 2024 5:09 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: sdwagrsv not equal rbgrsave
>>
>> Simple experimentation will show what you need to know about what is saved 
>> where.
>> For example, suppose your mainline links to another routine.You mainline's 
>> RB and the LINK target's RB can be examined.
>> Or suppose your mainline has an ESTAE and abends.You can examine the 
>> mainline's RB, then the (next newer) RTM SVRB, then the (next newer) ESTAE 
>> routine's PRB.
>> If you were trying to think about why it does what you will figure out that 
>> it does, you'd realize that the regs that the SVC interrupt handler 
>> processing wants to use have to be saved really quickly but the PSW is 
>> already captured (in SVC Old PSW).
>>
>> 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 

Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

[Phil Smith III]

Leonard D Woren wrote, in part:
>Software can be hacked.

Um. And? What's your point? Anything can be hacked:
https://xkcd.com/538/

The phrase "security by obscurity" has bothered me for years. It's *ALL* 
security by obscurity. If you have enough "stuff"-time, money, guns 
(wrenches)-you can get in. The trick is to make it hard enough that you outrun 
the bear.

For example, 256-bit AES can be broken by brute force-if you have until the end 
of time. (And if you'll know it when you see it, another issue.) But that 
"until the end of time" means you can use it to outrun the bear.

When people say "That's security by obscurity", they really mean "That's weak 
security because the barriers aren't high enough". That's all. It's not a big 
revelation.

.phsiii


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

VolCat - Reallocate ?

[Shaffer, Terri]

Hi,
  So I need to reallocate my VOLCAT, due to IMBED and REPLICATE present.

So my question is what steps to perform? Like This maybe?

Stop OAM?
Export VOLCAT?
Delete VOLCAT
ALLOCATE new VOLCAT.
IMPORT from Exported copy?
Start OAM?

Is this right, anyone have JCL example of EXP/IMPORT of a volcat?

Or anything I am missing?
Thanks

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com



 [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] 

This email message and any attachments may contain confidential, proprietary or 
non-public information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

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

Re: sdwagrsv not equal rbgrsave

[Seymour J Metz]

So after the ABEND but before the dump there was further activity, changing the 
registers in the dump. Where does your PC routine store registers?

I'm pretty sure that in your scenario you need to use the values in the SDWA, 
but perhaps Peter can clarify.

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


From: IBM Mainframe Discussion List  on behalf of 
Joseph Reichman 
Sent: Tuesday, January 16, 2024 9:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: sdwagrsv not equal rbgrsave

I was running under TESTAUTH

I produced an abend in a space switching pc stacking routine

SDWAEC2 matched up with the linkage stack PSW

SDWAEC1 matched up with RBOPSW of SDWARBAD sdwagrsv didn’t match the rb regs
Chaining back RBLINK equal TCB so I was at the end of the RBs

> On Jan 16, 2024, at 9:39 AM, Seymour J Metz  wrote:
>
> Was it SRB or TCB? Which RBs did you look at.
>
> Providing more details in your questions would enable better answers. If you 
> have a situation where you're not allowed to post details, it's best to say 
> so up front.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Joseph Reichman 
> Sent: Tuesday, January 16, 2024 9:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: sdwagrsv not equal rbgrsave
>
> Seymour in my case sdawgrsv wasn’t in either TCB regs or rb regs
>
> Im sure Peter knows where they are located if they are in some  internal IBM 
> controls block ( in which case he can not or it would be useless to tell me)
>
> But I just don’t think that’s the case
>
>> On Jan 16, 2024, at 9:29 AM, Seymour J Metz  wrote:
>>
>> Logic does not dictate where to store registers; there are at least two 
>> equally logical locations. In a z/OS TCB environment, the RB holds the 
>> caller's registers and the TCB holds the current registers with a few 
>> exceptions. This is documented.
>>
>> For SRB mode I'm not sure how much is GUPI.
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>> עַם יִשְׂרָאֵל חַי
>> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> Joseph Reichman 
>> Sent: Tuesday, January 16, 2024 8:34 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: sdwagrsv not equal rbgrsave
>>
>> Peter
>>
>> Its my understanding that everything in the SDWA is copied from another 
>> control block somewhere in the case of SDWAEC2 you helped me locate that in 
>> the linkage stack.
>>
>> For SDWAEC1 I was able to locate that in the RBOPSW of SDWARBAD
>>
>> My logic tells me that PSW and REGS go together but when I tried to match up 
>> SDWAGRSV to TBGRSAVE it didn’t.
>>
>> I think tried chaining back via RBLINK, but I got the TCB address meaning it 
>> was the end of the chain.
>>
>> Grasping at straws I looked at TCBREGS, but it was there either.
>>
>> If the error regs SDWAGRSV are in some private IBM control block I can 
>> understand that you cannot, or it would be useless to tell me.
>>
>> But my gut tells me it somewhere I can access it.
>>
>>
>> thanks
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf Of 
>> Peter Relson
>> Sent: Tuesday, January 16, 2024 5:09 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: sdwagrsv not equal rbgrsave
>>
>> Simple experimentation will show what you need to know about what is saved 
>> where.
>> For example, suppose your mainline links to another routine.You mainline's 
>> RB and the LINK target's RB can be examined.
>> Or suppose your mainline has an ESTAE and abends.You can examine the 
>> mainline's RB, then the (next newer) RTM SVRB, then the (next newer) ESTAE 
>> routine's PRB.
>> If you were trying to think about why it does what you will figure out that 
>> it does, you'd realize that the regs that the SVC interrupt handler 
>> processing wants to use have to be saved really quickly but the PSW is 
>> already captured (in SVC Old PSW).
>>
>> 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
>
> --
> For IBM-MAIN subscribe / signoff / 

Sv: Custom ISPF command

[Lars Höglund]

3.9 

 Menu  Utilities  Help
ss 
Display APCMDS   Row 5 to 38 of 47 
Command ===>  Scroll ===> CSR  
   
The command table is currently open, it cannot be modified. Use the view(V)
row command to see an entire entry.
   
 Verb  T  Action   
 VC0  SELECT CMD(%VCURSOR )  



-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List  För Lionel B. 
Dyck
Skickat: den 16 januari 2024 16:23
Till: IBM-MAIN@LISTSERV.UA.EDU
Ämne: Re: Custom ISPF command

Create a site ISPF command table and add your commands to that.

See ISPF 3.9 and it will show you the defined ISPF command tables. There is one 
for each application (i.e. ISR), and then up to 3 user tables, 3 site tables, 
and one system table (ISP).

You define the command table names (prefixes) using TSO ISPCCONF to update the 
ISPF configuration table which is a load module for your linklist or steplib or 
ispllib.

Hope this helps point you in the right direction.


Lionel B. Dyck <><
Github: https://github.com/lbdyck

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Tuesday, January 16, 2024 9:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Custom ISPF command

(It is better to ask than to stay uninformed)


I have created few simple REXX scripts for other folks.
Such script is located in SYSEXEC concatenation, so it can be issued using TSO 
SCRIPT1 or TSO SCRIPT2 PARM Recently I was asked to "make it ISPF native" - 
mean no TSO prefix in the command.
I believe it is feasible, but... how to do it?

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

--
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: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

[Lennie Dymoke-Bradshaw]

Radoslaw Skorupka wrote

> Note: Dataset Encryption (DSE) is *not* a replacement for RACF or other 
> security system.
> It is a solution to keep data secret even if you have (unintended) access to 
> the dataset. Bad RACF authority? NO!
> It could be administrative access via STGADMIN, shared DASD, etc.

I think z/OS data set encryption is a solution for protecting z/OS data when it 
is accessed outside of its normal environment. That could be via specialised 
authorised programs (such as ADRDSSU), via other systems (when a volume is 
accessed by a z/OS system using a different RACF database), where a volume is 
accessed by another operating system (such as z/VM or Linux), where a data set 
backup is transported to another system entirely, or any other situation where 
the data is not under its normal RACF controls. 

Lennie Dymoke-Bradshaw
https: //rsclweb.com

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

Re: Custom ISPF command

[Lionel B. Dyck]

Create a site ISPF command table and add your commands to that.

See ISPF 3.9 and it will show you the defined ISPF command tables. There is one 
for each application (i.e. ISR), and then up to 3 user tables, 3 site tables, 
and one system table (ISP).

You define the command table names (prefixes) using TSO ISPCCONF to update the 
ISPF configuration table which is a load module for your linklist or steplib or 
ispllib.

Hope this helps point you in the right direction.


Lionel B. Dyck <><
Github: https://github.com/lbdyck

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Tuesday, January 16, 2024 9:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Custom ISPF command

(It is better to ask than to stay uninformed)


I have created few simple REXX scripts for other folks.
Such script is located in SYSEXEC concatenation, so it can be issued using TSO 
SCRIPT1 or TSO SCRIPT2 PARM Recently I was asked to "make it ISPF native" - 
mean no TSO prefix in the command.
I believe it is feasible, but... how to do it?

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

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

Custom ISPF command

[Radoslaw Skorupka]

(It is better to ask than to stay uninformed)


I have created few simple REXX scripts for other folks.
Such script is located in SYSEXEC concatenation, so it can be issued 
using TSO SCRIPT1 or TSO SCRIPT2 PARM
Recently I was asked to "make it ISPF native" - mean no TSO prefix in 
the command.

I believe it is feasible, but... how to do it?

--
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: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

[Radoslaw Skorupka]

W dniu 16.01.2024 o 03:13, Michael Stein pisze:

On Mon, Jan 15, 2024 at 02:41:45PM -0600, Walt Farrell wrote:

On Mon, 15 Jan 2024 16:15:38 +, Eric D Rossman  wrote:
For encryption, the analogous method might be: Once a jobstep has
Opened an encrypted data set to read it, they cannot write to, nor Open,
an unencrypted output data set. You just mark the jobstep, and have a
bit in the DEB indicating encryption, and for a marked jobstep you don't
allow a write to a DEB that doesn't have the bit set.

So I could write the secret decrypted data out to an encrypted dataset
which had a different encryption key -- one which I had easier access
to?

Security is hard, especially read security.


Yes, you can have open for input and/or output many datasets. Any of 
them may be unencrypted, encrypted with key A, or key B, C, etc. You can 
copy data between those datasets.

Assumption:
1. you are authorized to each of the datasets in DATASET class.
2. You have READ access to key A, B, C, etc.

Note: Dataset Encryption (DSE) is *not* a replacement for RACF or other 
security system.
It is a solution to keep data secret even if you have (unintended) 
access to the dataset. Bad RACF authority? NO!

It could be administrative access via STGADMIN, shared DASD, etc.




--
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: sdwagrsv not equal rbgrsave

[Joseph Reichman]

I was running under TESTAUTH 

I produced an abend in a space switching pc stacking routine 

SDWAEC2 matched up with the linkage stack PSW 

SDWAEC1 matched up with RBOPSW of SDWARBAD sdwagrsv didn’t match the rb regs 
Chaining back RBLINK equal TCB so I was at the end of the RBs

> On Jan 16, 2024, at 9:39 AM, Seymour J Metz  wrote:
> 
> Was it SRB or TCB? Which RBs did you look at.
> 
> Providing more details in your questions would enable better answers. If you 
> have a situation where you're not allowed to post details, it's best to say 
> so up front.
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
> 
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Joseph Reichman 
> Sent: Tuesday, January 16, 2024 9:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: sdwagrsv not equal rbgrsave
> 
> Seymour in my case sdawgrsv wasn’t in either TCB regs or rb regs
> 
> Im sure Peter knows where they are located if they are in some  internal IBM 
> controls block ( in which case he can not or it would be useless to tell me)
> 
> But I just don’t think that’s the case
> 
>> On Jan 16, 2024, at 9:29 AM, Seymour J Metz  wrote:
>> 
>> Logic does not dictate where to store registers; there are at least two 
>> equally logical locations. In a z/OS TCB environment, the RB holds the 
>> caller's registers and the TCB holds the current registers with a few 
>> exceptions. This is documented.
>> 
>> For SRB mode I'm not sure how much is GUPI.
>> 
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>> עַם יִשְׂרָאֵל חַי
>> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>> 
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> Joseph Reichman 
>> Sent: Tuesday, January 16, 2024 8:34 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: sdwagrsv not equal rbgrsave
>> 
>> Peter
>> 
>> Its my understanding that everything in the SDWA is copied from another 
>> control block somewhere in the case of SDWAEC2 you helped me locate that in 
>> the linkage stack.
>> 
>> For SDWAEC1 I was able to locate that in the RBOPSW of SDWARBAD
>> 
>> My logic tells me that PSW and REGS go together but when I tried to match up 
>> SDWAGRSV to TBGRSAVE it didn’t.
>> 
>> I think tried chaining back via RBLINK, but I got the TCB address meaning it 
>> was the end of the chain.
>> 
>> Grasping at straws I looked at TCBREGS, but it was there either.
>> 
>> If the error regs SDWAGRSV are in some private IBM control block I can 
>> understand that you cannot, or it would be useless to tell me.
>> 
>> But my gut tells me it somewhere I can access it.
>> 
>> 
>> thanks
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf Of 
>> Peter Relson
>> Sent: Tuesday, January 16, 2024 5:09 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: sdwagrsv not equal rbgrsave
>> 
>> Simple experimentation will show what you need to know about what is saved 
>> where.
>> For example, suppose your mainline links to another routine.You mainline's 
>> RB and the LINK target's RB can be examined.
>> Or suppose your mainline has an ESTAE and abends.You can examine the 
>> mainline's RB, then the (next newer) RTM SVRB, then the (next newer) ESTAE 
>> routine's PRB.
>> If you were trying to think about why it does what you will figure out that 
>> it does, you'd realize that the regs that the SVC interrupt handler 
>> processing wants to use have to be saved really quickly but the PSW is 
>> already captured (in SVC Old PSW).
>> 
>> 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
> 
> --
> 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: sdwagrsv not equal rbgrsave

[Seymour J Metz]

Was it SRB or TCB? Which RBs did you look at.

Providing more details in your questions would enable better answers. If you 
have a situation where you're not allowed to post details, it's best to say so 
up front.

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


From: IBM Mainframe Discussion List  on behalf of 
Joseph Reichman 
Sent: Tuesday, January 16, 2024 9:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: sdwagrsv not equal rbgrsave

Seymour in my case sdawgrsv wasn’t in either TCB regs or rb regs

Im sure Peter knows where they are located if they are in some  internal IBM 
controls block ( in which case he can not or it would be useless to tell me)

But I just don’t think that’s the case

> On Jan 16, 2024, at 9:29 AM, Seymour J Metz  wrote:
>
> Logic does not dictate where to store registers; there are at least two 
> equally logical locations. In a z/OS TCB environment, the RB holds the 
> caller's registers and the TCB holds the current registers with a few 
> exceptions. This is documented.
>
> For SRB mode I'm not sure how much is GUPI.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Joseph Reichman 
> Sent: Tuesday, January 16, 2024 8:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: sdwagrsv not equal rbgrsave
>
> Peter
>
> Its my understanding that everything in the SDWA is copied from another 
> control block somewhere in the case of SDWAEC2 you helped me locate that in 
> the linkage stack.
>
> For SDWAEC1 I was able to locate that in the RBOPSW of SDWARBAD
>
> My logic tells me that PSW and REGS go together but when I tried to match up 
> SDWAGRSV to TBGRSAVE it didn’t.
>
> I think tried chaining back via RBLINK, but I got the TCB address meaning it 
> was the end of the chain.
>
> Grasping at straws I looked at TCBREGS, but it was there either.
>
> If the error regs SDWAGRSV are in some private IBM control block I can 
> understand that you cannot, or it would be useless to tell me.
>
> But my gut tells me it somewhere I can access it.
>
>
> thanks
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Peter Relson
> Sent: Tuesday, January 16, 2024 5:09 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: sdwagrsv not equal rbgrsave
>
> Simple experimentation will show what you need to know about what is saved 
> where.
> For example, suppose your mainline links to another routine.You mainline's RB 
> and the LINK target's RB can be examined.
> Or suppose your mainline has an ESTAE and abends.You can examine the 
> mainline's RB, then the (next newer) RTM SVRB, then the (next newer) ESTAE 
> routine's PRB.
> If you were trying to think about why it does what you will figure out that 
> it does, you'd realize that the regs that the SVC interrupt handler 
> processing wants to use have to be saved really quickly but the PSW is 
> already captured (in SVC Old PSW).
>
> 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

--
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: sdwagrsv not equal rbgrsave

[Joseph Reichman]

Seymour in my case sdawgrsv wasn’t in either TCB regs or rb regs 

Im sure Peter knows where they are located if they are in some  internal IBM 
controls block ( in which case he can not or it would be useless to tell me) 

But I just don’t think that’s the case 

> On Jan 16, 2024, at 9:29 AM, Seymour J Metz  wrote:
> 
> Logic does not dictate where to store registers; there are at least two 
> equally logical locations. In a z/OS TCB environment, the RB holds the 
> caller's registers and the TCB holds the current registers with a few 
> exceptions. This is documented.
> 
> For SRB mode I'm not sure how much is GUPI.
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
> 
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Joseph Reichman 
> Sent: Tuesday, January 16, 2024 8:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: sdwagrsv not equal rbgrsave
> 
> Peter
> 
> Its my understanding that everything in the SDWA is copied from another 
> control block somewhere in the case of SDWAEC2 you helped me locate that in 
> the linkage stack.
> 
> For SDWAEC1 I was able to locate that in the RBOPSW of SDWARBAD
> 
> My logic tells me that PSW and REGS go together but when I tried to match up 
> SDWAGRSV to TBGRSAVE it didn’t.
> 
> I think tried chaining back via RBLINK, but I got the TCB address meaning it 
> was the end of the chain.
> 
> Grasping at straws I looked at TCBREGS, but it was there either.
> 
> If the error regs SDWAGRSV are in some private IBM control block I can 
> understand that you cannot, or it would be useless to tell me.
> 
> But my gut tells me it somewhere I can access it.
> 
> 
> thanks
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Peter Relson
> Sent: Tuesday, January 16, 2024 5:09 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: sdwagrsv not equal rbgrsave
> 
> Simple experimentation will show what you need to know about what is saved 
> where.
> For example, suppose your mainline links to another routine.You mainline's RB 
> and the LINK target's RB can be examined.
> Or suppose your mainline has an ESTAE and abends.You can examine the 
> mainline's RB, then the (next newer) RTM SVRB, then the (next newer) ESTAE 
> routine's PRB.
> If you were trying to think about why it does what you will figure out that 
> it does, you'd realize that the regs that the SVC interrupt handler 
> processing wants to use have to be saved really quickly but the PSW is 
> already captured (in SVC Old PSW).
> 
> 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

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

Re: sdwagrsv not equal rbgrsave

[Seymour J Metz]

Logic does not dictate where to store registers; there are at least two equally 
logical locations. In a z/OS TCB environment, the RB holds the caller's 
registers and the TCB holds the current registers with a few exceptions. This 
is documented.

For SRB mode I'm not sure how much is GUPI.

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


From: IBM Mainframe Discussion List  on behalf of 
Joseph Reichman 
Sent: Tuesday, January 16, 2024 8:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: sdwagrsv not equal rbgrsave

Peter

Its my understanding that everything in the SDWA is copied from another control 
block somewhere in the case of SDWAEC2 you helped me locate that in the linkage 
stack.

For SDWAEC1 I was able to locate that in the RBOPSW of SDWARBAD

My logic tells me that PSW and REGS go together but when I tried to match up 
SDWAGRSV to TBGRSAVE it didn’t.

I think tried chaining back via RBLINK, but I got the TCB address meaning it 
was the end of the chain.

Grasping at straws I looked at TCBREGS, but it was there either.

If the error regs SDWAGRSV are in some private IBM control block I can 
understand that you cannot, or it would be useless to tell me.

But my gut tells me it somewhere I can access it.


thanks

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter Relson
Sent: Tuesday, January 16, 2024 5:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: sdwagrsv not equal rbgrsave

Simple experimentation will show what you need to know about what is saved 
where.
For example, suppose your mainline links to another routine.You mainline's RB 
and the LINK target's RB can be examined.
Or suppose your mainline has an ESTAE and abends.You can examine the mainline's 
RB, then the (next newer) RTM SVRB, then the (next newer) ESTAE routine's PRB.
If you were trying to think about why it does what you will figure out that it 
does, you'd realize that the regs that the SVC interrupt handler processing 
wants to use have to be saved really quickly but the PSW is already captured 
(in SVC Old PSW).

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: [EXTERNAL] Opinion

[Parry, Gary (PERATON)]

I have a similar model (LG 49WL95C-WE 32:9 UltraWide Monitor 49" Dual DQHD 
(5120 x 1440) IPS Display, HDR10, USB Type-C with 85W Power Delivery, Ambient 
Light Sensor, 2 x 10W Stereo Speaker with Rich Bass).  It's not as curved as 
other models - it feels almost flat, so that may be a concern.  The one you 
mention looks the same in that regard.  The Thunderbolt 4 with the 5K does 
deliver a nice, crisp, easy to read display.  I had to get used to multiple 
overlapping windows open all the time and I've settled on an arrangement that 
lets me see and get to important things quickly.  TN3270 dominates the center 
of the screen.  The biggest drawback for me is in screen sharing where I need 
to share specific windows instead of a whole screen.  I have not yet 
experimented with PowerToys' FancyZones.  Also, Teams popup notifications show 
in the far lower right corner of the display.  That took some getting used to..

Regards,
Gary Parry

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Monday, January 15, 2024 11:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Opinion

Does anyone have an opinion on

 

LG - 49" IPS LED Curved UltraWide Dual QHD 144Hz FreeSync and G-SYNC Compatible 
Monitor with HDR (HDMI, DisplayPort, USB) - Black

 

 

Steve Beaver

 


--
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: Traversing The Linkage Stack

[Joseph Reichman]

Peter 

By you pointing out that the entry descriptor  
Was at the end of the linkage stack you were able to locate my error 

As I assumed that STCBLSDP which points to the entry descriptor was also the 
begging point of the linkage stack but it was not 
 Thank you for your help 

> On Jan 15, 2024, at 4:22 PM, Peter Relson 
> <056a472f7cb4-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Joe R wrote
> I got to a X'89' is a header  the doc say that decrementing that would 
> bring to a new linkage frame I specifically remember looking - 32 bytes from 
> there and it was all zeros.
> 
> Not having ready access to that document, but knowing who wrote it, I'll bet 
> that it does not say that. It certainly isn't true architecturally.
> 
> You might look again at the architectural definition of the header stack 
> entry (which I expect that that presentation shows correctly).
> Is it actually the case that you had only the one BAKR entry on the linkage 
> stack and that is why the preceding entry descriptor was for the header? If 
> so, of course there is nothing preceding that, which the rest of the 
> information in that entry descriptor would have indicated. 
> 
> I don't recall that you ever posted what the linkage stack looked like (you 
> showed only the entry descriptor and data that actually was irrelevant 
> because it was part of the next entry). If true, despite being asked about 
> doing so, why not? You misinterpreted data that you did not let the readers 
> see, made incorrect conclusions and started with that. Really? What can we do 
> to get you to post in a meaningful and useful way so that the kind readers of 
> IBM-Main can help (without wasting unnecessary time)? 
> 
> Peter Relsonz/OS Core Technology Design
> 
> 
> 
> 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: sdwagrsv not equal rbgrsave

[Joseph Reichman]

Peter

Its my understanding that everything in the SDWA is copied from another control 
block somewhere in the case of SDWAEC2 you helped me locate that in the linkage 
stack. 

For SDWAEC1 I was able to locate that in the RBOPSW of SDWARBAD

My logic tells me that PSW and REGS go together but when I tried to match up 
SDWAGRSV to TBGRSAVE it didn’t. 

I think tried chaining back via RBLINK, but I got the TCB address meaning it 
was the end of the chain.

Grasping at straws I looked at TCBREGS, but it was there either.

If the error regs SDWAGRSV are in some private IBM control block I can 
understand that you cannot, or it would be useless to tell me.

But my gut tells me it somewhere I can access it. 


thanks   

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter Relson
Sent: Tuesday, January 16, 2024 5:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: sdwagrsv not equal rbgrsave

Simple experimentation will show what you need to know about what is saved 
where.
For example, suppose your mainline links to another routine.You mainline's RB 
and the LINK target's RB can be examined.
Or suppose your mainline has an ESTAE and abends.You can examine the mainline's 
RB, then the (next newer) RTM SVRB, then the (next newer) ESTAE routine's PRB.
If you were trying to think about why it does what you will figure out that it 
does, you'd realize that the regs that the SVC interrupt handler processing 
wants to use have to be saved really quickly but the PSW is already captured 
(in SVC Old PSW).  

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: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

[Eric D Rossman]

I think you underestimate the difficulty in "hacking" the software and that 
"single spit" of data is much more protected than you let on.

As for an IBMer "admitt[ing] that [you were] correct," I strongly suspect that 
you read WAY more into such a statement than was actually there.

Your PS wasn't terribly worrisome either. Of course someone knows all the key 
part holders to be able to bring them in. That's standard security practice. 
The risk isn't that someone knows the people. The risk is of collusion. If you 
have 3 key parts, you need 3 different people to all agree to act nefariously.

Eric Rossman

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Leonard D Woren
Sent: Monday, January 15, 2024 9:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Technical Reason? - Why you can't encrypt load 
libraries (PDSE format)?

OK.  So we've established that the key is set via software.

Software can be hacked.

And now there's only a single spit of data to focus all the effort on.  Years 
ago at a SHARE presentation, I caught an IBMer after the session and they 
admitted that I was correct.

/Leonard

P.S.  Someone has to know all the security officers in order to contact them 
when necessary to input the keys.

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

Re: Opinion

[Steve Beaver]

Thank you everyone for you feed back


Steve 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of kekronbekron
Sent: Tuesday, January 16, 2024 1:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Opinion

Chiming in to say that the big screen consideration is a real (seeing the whole 
screen without moving much) reason to want curved.
However, if you have 2 screens you can experiment with, just set them tilted in 
and see if that works for you.
I'm assuming big, curved screens cost more, compared to 2x 27" (or whatever) 
turned inwards.
Next thing to consider is 1080p vs 1440p vs higher.
BTW, dual or single, a dual-monitor arm is helpful and will be future proof, in 
case you get another later and want to mount it.



On Tuesday, January 16th, 2024 at 11:31, Brian Westerman 
 wrote:


> I have a 42 inch curved. The curved screen is very clear and everything is 
> the same size all the way from left to right. Previously I had a 42 in flat 
> screen (which I gave to my kid who loves it), but the problem I had was that 
> as I age, my eyesight isn't able to refocus as quickly so I had to actually 
> move my chair over to see things on the far left or right.
> 
> The curved screen resolved that issue because no matter where I look it 
> appears to be the same size and is clear without moving even my head very 
> much.
> 
> With a smaller screen (say 30 or 32 inch), I don't think it would be as big a 
> deal because the distance from side to side isn't really enough to cause any 
> distortion.
> 
> I think going to 49 inches would almost require it to be curved to be usable 
> as something to program with. With a big screen TV you are far enough back 
> from it that you don't see any real issues, but sitting just a couple feet 
> away makes a really big difference.
> 
> Brian
> 
> --
> 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: sdwagrsv not equal rbgrsave

[Peter Relson]

Simple experimentation will show what you need to know about what is saved 
where.
For example, suppose your mainline links to another routine.You mainline's RB 
and the LINK target's RB can be examined.
Or suppose your mainline has an ESTAE and abends.You can examine the mainline's 
RB, then the (next newer) RTM SVRB, then the (next newer) ESTAE routine's PRB.
If you were trying to think about why it does what you will figure out that it 
does, you'd realize that the regs that the SVC interrupt handler processing 
wants to use have to be saved really quickly but the PSW is already captured 
(in SVC Old PSW).  

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

Re: Direct branch entry to ICSF routines

[Peter Relson]

>Could you share why it matters to you if there is a linkage stack entry 
(whether before or after getting to the "true routine", even if my guess is 
right about what you think of as the "true routines")?

Performance. 

That doesn't provide much insight. 

What the callable services stub and the service do is generally the business of 
the stub and the service. For all I know, there is a BAKR on the front end and 
the target routine relies on being able to extract caller information from the 
linkage stack. 

It remains up to a caller to meet the interface requirements.
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