Re: CDE Extension for RMODE 64
R15 has bit 63 on I would assume Yes, reg 15 would be set up to be suitable for use by BSM 0,15 (AKA "pointer-defined") hence having bit 63 on when you want the target to be AMODE 64 (as you would need for an address above 2G). 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: CDE Extension for RMODE 64
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
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
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: CDE Extension for RMODE 64
Peter Thanks when is you say not every CDE is built by z/os are you referring to the IDENTIFY Macro which a user can could a CDE using a. Address in storage 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 Thanks > On Dec 25, 2023, at 12:18 PM, Joseph Reichman wrote: > > > Thank you > > Peter I started looking at it while trying to enhance the GRECOV > >>> On Dec 25, 2023, at 8:48 AM, Peter Relson wrote: >>> >> >> If bit CDCEX in the CDE meaning there is an CDE extension would that imply >> the module is RMODE 64 since CDXEntpt64 is a double word >> >> >> A simple glance at a CDE in storage for a module that is not RMODE 64 would >> show you that this is not the case. >> >> Every CDE built by z/OS has a CDX, as does every LPDE. The CDCDEX / LPDECDEX >> bit is on in each.. >> Not every CDE is necessarily built by z/OS (to our regret). >> >> A module is RMODE 64 (or has an RMODE 64 extent) if it has an extent that is >> above 2G. >> Extents are normally in the area pointed to by CDXLMJP of a major >> (non-alias) CDE. >> Since those extents have only 4 bytes for the extent address, that won't cut >> it for RMODE 64. >> >> A CDX (when it exists) might have an "XTL64". The interface parts of a CDX >> are mapped by IHACDX. The extent list 64 (mapped by IHAXTL64) has an 8-byte >> address for an extent. >> >> There is also the fine point of whether you are talking about "is the module >> defined as RMODE 64" or "is the module in 64-bit storage" or "is some extent >> of the module in 64-bit storage". >> >> The answer to the first question is within the directory entry. AMBLIST is >> one way to display that information (or doing a BLDL or a DESERV GET). >> The answer to the second and third questions lies with looking at the XTL64. >> If CDXXTLST64Addr is not 0 and if every extent is above 64 then you'd >> consider the answer to the second question to be "yes". >> If CDXXTLST64Addr is not 0 and if some extent is above 64 then you'd >> consider the answer to the third question to be "yes". >> If CDXXTLST64Addr is 0 then the answers to the 2nd and 3rd questions are >> "no". >> >> It does happen to be the case that if you look at the extent list pointed to >> by CDXLMJP, if one of the extents has an address >= x'7000', that >> correlates to "the extent is actually above 2G" and in that same entry the >> length is "1" (these being indicators that the real extent definition is in >> the XTL64 because it does not fit in the XTLST. >> >> 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
If bit CDCEX in the CDE meaning there is an CDE extension would that imply the module is RMODE 64 since CDXEntpt64 is a double word A simple glance at a CDE in storage for a module that is not RMODE 64 would show you that this is not the case. Every CDE built by z/OS has a CDX, as does every LPDE. The CDCDEX / LPDECDEX bit is on in each.. Not every CDE is necessarily built by z/OS (to our regret). A module is RMODE 64 (or has an RMODE 64 extent) if it has an extent that is above 2G. Extents are normally in the area pointed to by CDXLMJP of a major (non-alias) CDE. Since those extents have only 4 bytes for the extent address, that won't cut it for RMODE 64. A CDX (when it exists) might have an "XTL64". The interface parts of a CDX are mapped by IHACDX. The extent list 64 (mapped by IHAXTL64) has an 8-byte address for an extent. There is also the fine point of whether you are talking about "is the module defined as RMODE 64" or "is the module in 64-bit storage" or "is some extent of the module in 64-bit storage". The answer to the first question is within the directory entry. AMBLIST is one way to display that information (or doing a BLDL or a DESERV GET). The answer to the second and third questions lies with looking at the XTL64. If CDXXTLST64Addr is not 0 and if every extent is above 64 then you'd consider the answer to the second question to be "yes". If CDXXTLST64Addr is not 0 and if some extent is above 64 then you'd consider the answer to the third question to be "yes". If CDXXTLST64Addr is 0 then the answers to the 2nd and 3rd questions are "no". It does happen to be the case that if you look at the extent list pointed to by CDXLMJP, if one of the extents has an address >= x'7000', that correlates to "the extent is actually above 2G" and in that same entry the length is "1" (these being indicators that the real extent definition is in the XTL64 because it does not fit in the XTLST. 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: CDE Extension for RMODE 64
On Sun, 24 Dec 2023 19:01:06 -0500, Joseph Reichman wrote: >Just trying to figure if a module is rmode 64 > AMBLIST? -- gil -- 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
Just trying to figure if a module is rmode 64 Joe Reichman On Sun, Dec 24, 2023 at 7:00 PM Seymour J Metz wrote: > SPLIT? Or is that only 24/31? > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Discussion List on behalf > of Joseph Reichman > Sent: Sunday, December 24, 2023 6:34 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: CDE Extension for RMODE 64 > > HI > > If bit CDCEX in the CDE meaning there is an CDE extension would that imply > the module is RMODE 64 since CDXEntpt64 is a double word > > thanks > > -- > 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: CDE Extension for RMODE 64
SPLIT? Or is that only 24/31? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Joseph Reichman Sent: Sunday, December 24, 2023 6:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CDE Extension for RMODE 64 HI If bit CDCEX in the CDE meaning there is an CDE extension would that imply the module is RMODE 64 since CDXEntpt64 is a double word thanks -- 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
CDE Extension for RMODE 64
HI If bit CDCEX in the CDE meaning there is an CDE extension would that imply the module is RMODE 64 since CDXEntpt64 is a double word thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
