Re: CDE Extension for RMODE 64

2023-12-26 Thread Joseph Reichman
R15 has bit 63 on I would assume 

> On Dec 26, 2023, at 8:10 AM, Joseph Reichman  wrote:
> 
> Thank you
> 
> Still working on CBT file 192 general recovery
> 
> Routine
> 
>> On Dec 26, 2023, at 8:08 AM, Peter Relson  wrote:
>> 
>> 
>> when you say not every CDE is built  by z/os are you referring to the 
>> IDENTIFY Macro...?
>> 
>> 
>> No I am not. IDENTIFY is part of z/OS.
>> I am referring to non-z/OS programs that obtain storage for CDE's and chain 
>> them into the z/OS control structures such as the job pack queue TCBJPQ.
>> 
>> 
>> Also I noticed that the retry address is only 4 bytes.
>> I guess then to  you would have to retry to a label in the program that has 
>> RP instruction
>> And have your recovery set it up before returning to RTM
>> 
>> 
>> You noticed correctly. Neither retry addresses nor (more broadly) recovery 
>> routines can be above 2G.
>> However, your guess is not what anyone is likely to do.
>> The CVTBSM0F field was provided for this purpose.
>> You set up 64-bit retry reg 15 to the address of your above-the-bar retry 
>> address.
>> You make sure that that reg 15 will be used for retry (SETRP with 
>> RETRY15=YES, if an FRR; RETRY15 does not apply for ESTAE-type retry so that 
>> case is fine without RETRY15=YES).
>> You set up the retry address to the address of CVTBSM0F (not the contents of 
>> CVTBSM0F, that would not work).
>> You make sure retry is AMODE 64.
>> 
>> Retry goes to CVTBSM0F, the instruction there which is BSM 0,X'F' takes you 
>> to the target located by reg 15.
>> 
>> The system trace entry for that retry contains the value from reg 15, not 
>> the address of CVTBSM0F.
>> 
>> Aside from the trace entry manipulation, you could accomplish this by 
>> yourself with some other register if you had a need.
>> 
>> Peter Relson
>> z/OS Core Technology Design
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Re: CDE Extension for RMODE 64

2023-12-26 Thread Joseph Reichman
Thank you 

Still working on CBT file 192 general recovery 

Routine 

> On Dec 26, 2023, at 8:08 AM, Peter Relson  wrote:
> 
> 
> when you say not every CDE is built  by z/os are you referring to the 
> IDENTIFY Macro...?
> 
> 
> No I am not. IDENTIFY is part of z/OS.
> I am referring to non-z/OS programs that obtain storage for CDE's and chain 
> them into the z/OS control structures such as the job pack queue TCBJPQ.
> 
> 
> Also I noticed that the retry address is only 4 bytes.
> I guess then to  you would have to retry to a label in the program that has 
> RP instruction
> And have your recovery set it up before returning to RTM
> 
> 
> You noticed correctly. Neither retry addresses nor (more broadly) recovery 
> routines can be above 2G.
> However, your guess is not what anyone is likely to do.
> The CVTBSM0F field was provided for this purpose.
> You set up 64-bit retry reg 15 to the address of your above-the-bar retry 
> address.
> You make sure that that reg 15 will be used for retry (SETRP with 
> RETRY15=YES, if an FRR; RETRY15 does not apply for ESTAE-type retry so that 
> case is fine without RETRY15=YES).
> You set up the retry address to the address of CVTBSM0F (not the contents of 
> CVTBSM0F, that would not work).
> You make sure retry is AMODE 64.
> 
> Retry goes to CVTBSM0F, the instruction there which is BSM 0,X'F' takes you 
> to the target located by reg 15.
> 
> The system trace entry for that retry contains the value from reg 15, not the 
> address of CVTBSM0F.
> 
> Aside from the trace entry manipulation, you could accomplish this by 
> yourself with some other register if you had a need.
> 
> Peter Relson
> z/OS Core Technology Design
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Re: CDE Extension for RMODE 64

2023-12-26 Thread Peter Relson

when you say not every CDE is built  by z/os are you referring to the IDENTIFY 
Macro...?


No I am not. IDENTIFY is part of z/OS.
I am referring to non-z/OS programs that obtain storage for CDE's and chain 
them into the z/OS control structures such as the job pack queue TCBJPQ.


Also I noticed that the retry address is only 4 bytes.
I guess then to  you would have to retry to a label in the program that has RP 
instruction
And have your recovery set it up before returning to RTM


You noticed correctly. Neither retry addresses nor (more broadly) recovery 
routines can be above 2G.
However, your guess is not what anyone is likely to do.
The CVTBSM0F field was provided for this purpose.
You set up 64-bit retry reg 15 to the address of your above-the-bar retry 
address.
You make sure that that reg 15 will be used for retry (SETRP with RETRY15=YES, 
if an FRR; RETRY15 does not apply for ESTAE-type retry so that case is fine 
without RETRY15=YES).
You set up the retry address to the address of CVTBSM0F (not the contents of 
CVTBSM0F, that would not work).
You make sure retry is AMODE 64.

Retry goes to CVTBSM0F, the instruction there which is BSM 0,X'F' takes you to 
the target located by reg 15.

The system trace entry for that retry contains the value from reg 15, not the 
address of CVTBSM0F.

Aside from the trace entry manipulation, you could accomplish this by yourself 
with some other register if you had a need.

Peter Relson
z/OS Core Technology Design

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


Re: ISPF to Panvalet interface

2023-12-26 Thread Brian Westerman
You're right, I made the changes to make it work and it does, but we get a 
violation for product X8 (Panvalet TSO), which I believe is bogus.  I'll call 
Broadcom to make sure we didn't violate anything, but I think that the modules 
necessary for Panvalet TSO are different than these and it is misinterpreting 
something.

BRian

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