Re: Testing address validity
They are callable services and how they are called in the manual you specified. Laddie Hanus Sent from whatever device I am using. > On Mar 8, 2022, at 12:36 PM, paul schuster wrote: > > Which z/os library are these IARBRVER, IARBRVEA, and IARBRVKA macros shipped > in? I don't see them in MACLIB or MODGEN. But they are documented in the > z/os 2.5 MVS Programming: Authorized > Assembler Services Reference, Volume 2 > (EDT-IXG) > > Thank you.
Re: Testing address validity
Which z/os library are these IARBRVER, IARBRVEA, and IARBRVKA macros shipped in? I don't see them in MACLIB or MODGEN. But they are documented in the z/os 2.5 MVS Programming: Authorized Assembler Services Reference, Volume 2 (EDT-IXG) Thank you.
Re: Testing address validity
We have a similar issue when following pointer chains that could have be corrupted. If you're only reading the storage, I think transactionalizing the code with TBEGIN/TEND will do this for you. If the transaction is successful, you have access, if it's not you don't. Don't know if this approach will actually work, it's the next new instruction facility I intend to play with, when I have the time. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of João Reginato Sent: Monday, March 7, 2022 12:17 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: RES: Testing address validity Importance: Low These macros are great. Thank you all by the discussion. Very useful -Mensagem original- De: IBM Mainframe Assembler List Em nome de Jeremy Schwartz Enviada em: sábado, 5 de março de 2022 17:14 Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU Assunto: Re: Testing address validity Just curious would the following macros work better as a replacement for TPROT in the requested case? IARBRVER, IARBRVEA, and IARBRVKA Regards, Jeremy Schwartz From: IBM Mainframe Assembler List on behalf of Philippe Leite Sent: Saturday, March 5, 2022 9:28 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity CAUTION: This message was sent from outside the company. Do not click links or open attachments unless you recognize the sender and know the content is safe. You can use TPROT for this purpose but it's a privileged instruction. Regards, Philippe Leite LAB Services - IBM Em sáb., 5 de mar. de 2022 09:45, João Reginato escreveu: > Hi > > Which is the best instruction to test if a virtual address is still > valid to avoid an unexpected S0C4? > > > > TIA > > João > > > --- NOTICE: This email and all attachments are confidential, may be proprietary, and may be privileged or otherwise protected from disclosure. They are intended solely for the individual or entity to whom the email is addressed. However, mistakes sometimes happen in addressing emails. If you believe that you are not an intended recipient, please stop reading immediately. Do not copy, forward, or rely on the contents in any way. Notify the sender and/or Imperva, Inc. by telephone at +1 (650) 832-6006 and then delete or destroy any copy of this email and its attachments. The sender reserves and asserts all rights to confidentiality, as well as any privileges that may apply. Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful. Please consider the environment before printing this email.
Re: Testing address validity
What IBM told us (sometime last century) is that when you get a CC=3 and you really want to know more, you establish a recovery routine, reference the storage (with a CLI or something similar) and then (after cleanup) re-issue the TPROT. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Seymour J Metz Sent: Saturday, March 5, 2022 19:28 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity How would you handle CC 3 from TPROT? Does z/VSE have a facility to request a page-in without treating an invalid virtual address as an error? -- Shmuel (Seymour J.) Metz
Re: Testing Address validity
> Simply attempt the access. We are in violent agreement. I'm not the one asking for the new instruction; I'm one of the ones saying that such an instruction wouldn't solve the TOCTTOU issue. > If it's a Supervisor function it must page-fix the buffer. No. It needs to copy data into protected storage, but generally that storage can be pageable. > I suppose access methods do all that routinely. With the exception of VSAM local shared resources, the access methods have separate user-side storage for each open ACB/DCB. For VSAM and VTAM, once you get beyond the user's private area, all bets are off. The last time that the code was available for customer scrutiny, there was page fixing of storage related to STARTIO, but I don't recall anything else that was page fixed. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] Sent: Sunday, March 6, 2022 2:31 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing Address validity On Mar 6, 2022, at 11:55:46, Seymour J Metz wrote: > > Well, if there was a burning need for it then they could add an instruction > that worked like TPROT but took an interrupt instead of a CC 3 for invalid > address. Even if you had it, there would stil be the TOFTTOU issue. > ??? Simply attempt the access. o If it fails, diagnose the interrupt code. o If it succeeds, you're done; no TOFTTOU. (Aren't we back where we started?) If callers intercept the interrupt, they are assuming the responsibility of diagnosing. (The documentation might warn them.) If it's a Supervisor function it must page-fix the buffer. After copying the pointer to protected storage. And ensuring that concurrent tasks don't use overleaping buffers. I suppose access methods do all that routinely. -- gil
Re: Testing Address validity
On Mar 6, 2022, at 11:55:46, Seymour J Metz wrote: > > Well, if there was a burning need for it then they could add an instruction > that worked like TPROT but took an interrupt instead of a CC 3 for invalid > address. Even if you had it, there would stil be the TOFTTOU issue. > ??? Simply attempt the access. o If it fails, diagnose the interrupt code. o If it succeeds, you're done; no TOFTTOU. (Aren't we back where we started?) If callers intercept the interrupt, they are assuming the responsibility of diagnosing. (The documentation might warn them.) If it's a Supervisor function it must page-fix the buffer. After copying the pointer to protected storage. And ensuring that concurrent tasks don't use overleaping buffers. I suppose access methods do all that routinely. -- gil
Re: Testing Address validity
Well, if there was a burning need for it then they could add an instruction that worked like TPROT but took an interrupt instead of a CC 3 for invalid address. Even if you had it, there would stil be the TOFTTOU issue. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Sunday, March 6, 2022 12:56 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing Address validity Okay, thanks all, and especially @Peter. 1. There is no burning need for such a facility. There already is an existing facility. If you are going to be accessing storage for which your access rights are questionable, use ESPIE. QED. 2. Basically, the problem with the instruction approach is that the OS is well-equipped to respond to an instruction with an interrupt; it is not well-equipped to respond with a generated condition code (for the reasons @Peter elucidates). The OS is not at all well-positioned to determine the failing opcode. I suppose if there were a burning need for such an instruction, the hardware would need to indicate in the page fault interrupt that it was the new instruction and required special treatment from the OS. If I am parsing things correctly, a hypothetical new instruction could readily deal with the "page exists, wrong key" situation -- on after-page-in retry it could just return the appropriate return code. It is the "no such virtual address" case that has the (purely software) problem above. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Peter Relson Sent: Sunday, March 6, 2022 5:34 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing Address validity I have an ordinary problem state program that attempts to access storage that it does not have access to. Obviously a S0C4 is the result. Let's say the address is a valid virtual address (but the storage key is wrong) and the page representing that virtual address is paged out. What is the sequence of events that leads to the S0C4? Does the OS have to page in the page so the hardware can generate a S0C4? That seems inefficient. And in any event, whatever the mechanism, why could not that mechanism generate a condition code for this hypothetical new instruction rather than a program interrupt? There has to be a program interrupt. Because that is the hardware's way of telling the software "I do not know". The hardware does not know anything beyond that the DAT structure indicates that the page is not valid. Is it "truly not valid" or is it "not valid because the OS has paged out the page"? The software could choose to provide a way to field that program interrupt and convert it into something that continues the user program. That is, after all, exactly what happens on a page fault. z/OS would not do that because it would not be a useful expenditure of resource. Taking a long time to field a user error is hardly a problem in any realistic situation. After all, the same user could have simply blown up themselves if they wanted to do so, without involving your service. So the net effect to the system is the same. As to the question about the flow, it's something like this: * Program/instruction references storage via a virtual address * Hardware determines that the virtual address is not backed by a real page and presents a program interrupt (there are quite a few possible such interrupts * OS program interrupt handler sees that program interrupt and queries its own data to determine if the reason that the virtual address is not backed by a real page is because the page has been paged out to some form of auxiliary storage * OS would generally let the fault continue to some recovery process if the page is not available on aux * If the page is available on aux, OS would generally suspend the program, bring in the page from aux by some asynchronous process (it can be synchronous for such cases as DREF or SCM in which case suspend/resume would not be needed), then resume the program to "try again". The desire to "try again" is why these program interrupts occur without a PSW address update, allowing for easy "try again". So, sure, in the middle of the above the OS could have said "the page is on aux, but I'm not going to bring it in, and if I can tell that the instruction being issued was some new "test only" instruction then set up to continue the interrupted program with an indicator such as a condition code (or anything else it chose to make the interface, even a "return code"). This is not instruction architecture. This is software programming interface. z/OS would not mplement such a thing. There is no guarantee even that the oper
Re: Testing Address validity
Okay, thanks all, and especially @Peter. 1. There is no burning need for such a facility. There already is an existing facility. If you are going to be accessing storage for which your access rights are questionable, use ESPIE. QED. 2. Basically, the problem with the instruction approach is that the OS is well-equipped to respond to an instruction with an interrupt; it is not well-equipped to respond with a generated condition code (for the reasons @Peter elucidates). The OS is not at all well-positioned to determine the failing opcode. I suppose if there were a burning need for such an instruction, the hardware would need to indicate in the page fault interrupt that it was the new instruction and required special treatment from the OS. If I am parsing things correctly, a hypothetical new instruction could readily deal with the "page exists, wrong key" situation -- on after-page-in retry it could just return the appropriate return code. It is the "no such virtual address" case that has the (purely software) problem above. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Peter Relson Sent: Sunday, March 6, 2022 5:34 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing Address validity I have an ordinary problem state program that attempts to access storage that it does not have access to. Obviously a S0C4 is the result. Let's say the address is a valid virtual address (but the storage key is wrong) and the page representing that virtual address is paged out. What is the sequence of events that leads to the S0C4? Does the OS have to page in the page so the hardware can generate a S0C4? That seems inefficient. And in any event, whatever the mechanism, why could not that mechanism generate a condition code for this hypothetical new instruction rather than a program interrupt? There has to be a program interrupt. Because that is the hardware's way of telling the software "I do not know". The hardware does not know anything beyond that the DAT structure indicates that the page is not valid. Is it "truly not valid" or is it "not valid because the OS has paged out the page"? The software could choose to provide a way to field that program interrupt and convert it into something that continues the user program. That is, after all, exactly what happens on a page fault. z/OS would not do that because it would not be a useful expenditure of resource. Taking a long time to field a user error is hardly a problem in any realistic situation. After all, the same user could have simply blown up themselves if they wanted to do so, without involving your service. So the net effect to the system is the same. As to the question about the flow, it's something like this: * Program/instruction references storage via a virtual address * Hardware determines that the virtual address is not backed by a real page and presents a program interrupt (there are quite a few possible such interrupts * OS program interrupt handler sees that program interrupt and queries its own data to determine if the reason that the virtual address is not backed by a real page is because the page has been paged out to some form of auxiliary storage * OS would generally let the fault continue to some recovery process if the page is not available on aux * If the page is available on aux, OS would generally suspend the program, bring in the page from aux by some asynchronous process (it can be synchronous for such cases as DREF or SCM in which case suspend/resume would not be needed), then resume the program to "try again". The desire to "try again" is why these program interrupts occur without a PSW address update, allowing for easy "try again". So, sure, in the middle of the above the OS could have said "the page is on aux, but I'm not going to bring it in, and if I can tell that the instruction being issued was some new "test only" instruction then set up to continue the interrupted program with an indicator such as a condition code (or anything else it chose to make the interface, even a "return code"). This is not instruction architecture. This is software programming interface. z/OS would not mplement such a thing. There is no guarantee even that the operating system can determine the instruction. That information is not part of program interrupt information, and it is theoretically possible for the page(s) with the instruction to be paged out by an asynchronous process before the program interrupt handler could look.
Re: Testing Address validity
On 3/6/2022 5:33 AM, Peter Relson wrote: * If the page is available on aux, OS would generally suspend the program, bring in the page from aux by some asynchronous process (it can be synchronous for such cases as DREF or SCM in which case suspend/resume would not be needed)... It never occurred to me to wonder if SCM page retrieval was a synchronous process. Thanks for the enlightenment! -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Testing Address validity
I have an ordinary problem state program that attempts to access storage that it does not have access to. Obviously a S0C4 is the result. Let's say the address is a valid virtual address (but the storage key is wrong) and the page representing that virtual address is paged out. What is the sequence of events that leads to the S0C4? Does the OS have to page in the page so the hardware can generate a S0C4? That seems inefficient. And in any event, whatever the mechanism, why could not that mechanism generate a condition code for this hypothetical new instruction rather than a program interrupt? There has to be a program interrupt. Because that is the hardware's way of telling the software "I do not know". The hardware does not know anything beyond that the DAT structure indicates that the page is not valid. Is it "truly not valid" or is it "not valid because the OS has paged out the page"? The software could choose to provide a way to field that program interrupt and convert it into something that continues the user program. That is, after all, exactly what happens on a page fault. z/OS would not do that because it would not be a useful expenditure of resource. Taking a long time to field a user error is hardly a problem in any realistic situation. After all, the same user could have simply blown up themselves if they wanted to do so, without involving your service. So the net effect to the system is the same. As to the question about the flow, it's something like this: * Program/instruction references storage via a virtual address * Hardware determines that the virtual address is not backed by a real page and presents a program interrupt (there are quite a few possible such interrupts * OS program interrupt handler sees that program interrupt and queries its own data to determine if the reason that the virtual address is not backed by a real page is because the page has been paged out to some form of auxiliary storage * OS would generally let the fault continue to some recovery process if the page is not available on aux * If the page is available on aux, OS would generally suspend the program, bring in the page from aux by some asynchronous process (it can be synchronous for such cases as DREF or SCM in which case suspend/resume would not be needed), then resume the program to "try again". The desire to "try again" is why these program interrupts occur without a PSW address update, allowing for easy "try again". So, sure, in the middle of the above the OS could have said "the page is on aux, but I'm not going to bring it in, and if I can tell that the instruction being issued was some new "test only" instruction then set up to continue the interrupted program with an indicator such as a condition code (or anything else it chose to make the interface, even a "return code"). This is not instruction architecture. This is software programming interface. z/OS would not mplement such a thing. There is no guarantee even that the operating system can determine the instruction. That information is not part of program interrupt information, and it is theoretically possible for the page(s) with the instruction to be paged out by an asynchronous process before the program interrupt handler could look. Just about the only productive use of TPROT is when you are supervisor state and have reason to know that the storage being accessed is supposed to be page-fixed. In that case a CC=3 from TPROT can be known to indicate "bad". z/OS itself uses this sometimes. Peter Relson z/OS Core Technology Design
Re: Testing address validity
On Sat, 5 Mar 2022 at 19:48, Charles Mills wrote: > > I guess I am unclear on the sequence of events involved. Serious question, > not an argument: > > I have an ordinary problem state program that attempts to access storage > that it does not have access to. Obviously a S0C4 is the result. Let's say > the address is a valid virtual address (but the storage key is wrong) and > the page representing that virtual address is paged out. What is the > sequence of events that leads to the S0C4? Does the OS have to page in the > page so the hardware can generate a S0C4? That seems inefficient. [My interpretation of the PofO; yours may be different and/or just as good:] Keep in mind that pages (of virtual storage) don't have things like a storage key and change and reference bits. Only page frames (blocks of real storage) have that stuff. (Yes, there is the IVSK instruction, but that still ultimately deals with real storage, and will itself get a page fault if there is no valid translation to the real address of the page. I believe it exists to avoid the risk of an interrupt between LRA and ISK[E] that could otherwise arise.) So if the address is in a page that's paged out, the page table entry will be marked as invalid. This leads to a program interrupt 11 (page fault). If the virtual storage for that page is not allocated, then the program interrupt 11 will be converted into a S0C4 abend. If the page exists in a slot in a page dataset, z/OS will page it in and retry the failing instruction. If there is a key mismatch at that point it gets a program interrupt 4 (protection exception), and this is also turned into a S0C4 abend. So by this description, yes, the OS has to page in the page to discover the protection exception. But... If the Invalid bit is on in the page table entry, the other 63 bits are available for software use, and I imagine that z/OS keeps information there about the key and the status of the page in auxiliary storage, and so should be able to issue the S0C4 without having to do the page-in. But that's z/OS, not the architecture, and I don't know what it really does under those OCO covers. > And in any event, whatever the mechanism, why could not that mechanism > generate a condition code for this hypothetical new instruction rather than > a program interrupt? It could if the architecture defined a place to keep the key for the page. But as far as I know it doesn't. Tony H.
Re: Testing address validity
There really isone. If you're authorized, TPROT will help, but there are three problems: 1. It requires Supervisor mode. 2. I requires that you be in the correct addressing environment. 3. It gives a condition code three with no useful information if the data are paged out. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of João Reginato [jb.regin...@gmail.com] Sent: Saturday, March 5, 2022 7:44 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Testing address validity Hi Which is the best instruction to test if a virtual address is still valid to avoid an unexpected S0C4? TIA João
Re: Testing address validity
How would you handle CC 3 from TPROT? Does z/VSE have a facility to request a page-in without treating an invalid virtual address as an error? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tony Thigpen [t...@vse2pdf.com] Sent: Saturday, March 5, 2022 7:39 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity z/VSE and running on the callers TCB (for several z/VSE related reasons). Tony Thigpen Seymour J Metz wrote on 3/5/22 19:35: > As a subsystem, you should have your own recovery environment, so what you do > won't interfere with the caller's error recovery. Using a recovery routine, > whether to handle a program check or to handle the ABEND from an unhandled > program check, has two advantages: > > 1. It works when the data were paged out > > 2. It solves the time-of-check to time-of-use problem. > > > -- > Shmuel (Seymour J.) Metz > https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7Csmetz3%40gmu.edu%7C5eb4f155d5e348a4f78008d9ff09d6ef%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637821240001763574%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Q3IlautNVBoE6qUYgjR%2FwOqI3QhfFhBJU6761VPOuSs%3Dreserved=0 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Tony Thigpen [t...@vse2pdf.com] > Sent: Saturday, March 5, 2022 5:11 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Testing address validity > > My thoughts. > > Since I support software that is called by any number of users, I would > like to validate that they provided valid parms. As a called subsystem, > I can't be messing with the callers error handling routines that may > already be handling SOC4s. I don't want to know if it's 'in storage', > just that it is accessible even if a page-fault is needed. > > I wish there was a simple: > TEST MEMORY AND BRANCH INVALID > operands R1 is a register pair with R1=address and R1+1=length to > validate. (Like an MVCL.) > > Instead of a SOC4, just branch to the address provided as the second > operand where I have placed an error handler. > > > > Tony Thigpen > > Paul Gilmartin wrote on 3/5/22 16:48: >> On Mar 5, 2022, at 05:44:41, João Reginato wrote: >>> >>> Which is the best instruction to test if a virtual address is still valid to >>> avoid an unexpected S0C4? >>> >> How is that information useful? >> >> Is its usefulness diminished by "an unexpected S0C4"? >> >> -- >> gil
Re: Testing address validity
Yes, and they will report it if TPROT gives cc=3. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Jeremy Schwartz [115e2ee20c83-dmarc-requ...@listserv.uga.edu] Sent: Saturday, March 5, 2022 3:13 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity Just curious would the following macros work better as a replacement for TPROT in the requested case? IARBRVER, IARBRVEA, and IARBRVKA Regards, Jeremy Schwartz From: IBM Mainframe Assembler List on behalf of Philippe Leite Sent: Saturday, March 5, 2022 9:28 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity CAUTION: This message was sent from outside the company. Do not click links or open attachments unless you recognize the sender and know the content is safe. You can use TPROT for this purpose but it's a privileged instruction. Regards, Philippe Leite LAB Services - IBM Em sáb., 5 de mar. de 2022 09:45, João Reginato escreveu: > Hi > > Which is the best instruction to test if a virtual address is still valid > to > avoid an unexpected S0C4? > > > > TIA > > João > > > --- NOTICE: This email and all attachments are confidential, may be proprietary, and may be privileged or otherwise protected from disclosure. They are intended solely for the individual or entity to whom the email is addressed. However, mistakes sometimes happen in addressing emails. If you believe that you are not an intended recipient, please stop reading immediately. Do not copy, forward, or rely on the contents in any way. Notify the sender and/or Imperva, Inc. by telephone at +1 (650) 832-6006 and then delete or destroy any copy of this email and its attachments. The sender reserves and asserts all rights to confidentiality, as well as any privileges that may apply. Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful. Please consider the environment before printing this email.
Re: Testing address validity
It is not obvious that there will be an S0C4. ESPIE can intercept codes related to various types of protection. The general sequence of events is 1. You get a program check. The Supervisor determines that it needs to page something in. 2. Upon redispatch, you attempt to use the data 3. You get a program check. The Supervisor determines that it does not need to page anything in. 4. The Supervisor determines whether there is an active SPIE or ESPIE for the interrupt code. 5. If the interrupt is not handled, the Supervisor calls RTM for an S0C4. That's z/OS, not the hardware. 6. The Supervisor calls any recovery routines. In the case of paged out data with the wrong key, the interrupt code for steps 3-4 will be 04. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Saturday, March 5, 2022 7:48 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity I guess I am unclear on the sequence of events involved. Serious question, not an argument: I have an ordinary problem state program that attempts to access storage that it does not have access to. Obviously a S0C4 is the result. Let's say the address is a valid virtual address (but the storage key is wrong) and the page representing that virtual address is paged out. What is the sequence of events that leads to the S0C4? Does the OS have to page in the page so the hardware can generate a S0C4? That seems inefficient. And in any event, whatever the mechanism, why could not that mechanism generate a condition code for this hypothetical new instruction rather than a program interrupt? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Saturday, March 5, 2022 4:27 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity > How does the hardware not know the answer to that question? Because the hardware only knows about pages assigned to pages; it knows nothing about what has been paged out, as was previously noted. -- Shmuel (Seymour J.) Metz https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7Csmetz3%40gmu.edu%7C1b7a1ea780c64d684a4408d9ff0b16a9%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637821245409672791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=1ovNT%2FKa3OZ%2BcIzXUaJtHjw4t2lHbKxuAk6YUUekvAY%3Dreserved=0 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Saturday, March 5, 2022 6:17 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity > only the OS knows the answer to this question Am I suffering from some mental block? How does the hardware not know the answer to that question? If an instruction can cause a S0C4, why could an instruction not answer this question? The hardware "knows" about virtual addresses.
Re: Testing address validity
I guess I am unclear on the sequence of events involved. Serious question, not an argument: I have an ordinary problem state program that attempts to access storage that it does not have access to. Obviously a S0C4 is the result. Let's say the address is a valid virtual address (but the storage key is wrong) and the page representing that virtual address is paged out. What is the sequence of events that leads to the S0C4? Does the OS have to page in the page so the hardware can generate a S0C4? That seems inefficient. And in any event, whatever the mechanism, why could not that mechanism generate a condition code for this hypothetical new instruction rather than a program interrupt? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Saturday, March 5, 2022 4:27 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity > How does the hardware not know the answer to that question? Because the hardware only knows about pages assigned to pages; it knows nothing about what has been paged out, as was previously noted. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Saturday, March 5, 2022 6:17 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity > only the OS knows the answer to this question Am I suffering from some mental block? How does the hardware not know the answer to that question? If an instruction can cause a S0C4, why could an instruction not answer this question? The hardware "knows" about virtual addresses.
Re: Testing address validity
z/VSE and running on the callers TCB (for several z/VSE related reasons). Tony Thigpen Seymour J Metz wrote on 3/5/22 19:35: As a subsystem, you should have your own recovery environment, so what you do won't interfere with the caller's error recovery. Using a recovery routine, whether to handle a program check or to handle the ABEND from an unhandled program check, has two advantages: 1. It works when the data were paged out 2. It solves the time-of-check to time-of-use problem. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tony Thigpen [t...@vse2pdf.com] Sent: Saturday, March 5, 2022 5:11 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity My thoughts. Since I support software that is called by any number of users, I would like to validate that they provided valid parms. As a called subsystem, I can't be messing with the callers error handling routines that may already be handling SOC4s. I don't want to know if it's 'in storage', just that it is accessible even if a page-fault is needed. I wish there was a simple: TEST MEMORY AND BRANCH INVALID operands R1 is a register pair with R1=address and R1+1=length to validate. (Like an MVCL.) Instead of a SOC4, just branch to the address provided as the second operand where I have placed an error handler. Tony Thigpen Paul Gilmartin wrote on 3/5/22 16:48: On Mar 5, 2022, at 05:44:41, João Reginato wrote: Which is the best instruction to test if a virtual address is still valid to avoid an unexpected S0C4? How is that information useful? Is its usefulness diminished by "an unexpected S0C4"? -- gil
Re: Testing address validity
As a subsystem, you should have your own recovery environment, so what you do won't interfere with the caller's error recovery. Using a recovery routine, whether to handle a program check or to handle the ABEND from an unhandled program check, has two advantages: 1. It works when the data were paged out 2. It solves the time-of-check to time-of-use problem. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tony Thigpen [t...@vse2pdf.com] Sent: Saturday, March 5, 2022 5:11 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity My thoughts. Since I support software that is called by any number of users, I would like to validate that they provided valid parms. As a called subsystem, I can't be messing with the callers error handling routines that may already be handling SOC4s. I don't want to know if it's 'in storage', just that it is accessible even if a page-fault is needed. I wish there was a simple: TEST MEMORY AND BRANCH INVALID operands R1 is a register pair with R1=address and R1+1=length to validate. (Like an MVCL.) Instead of a SOC4, just branch to the address provided as the second operand where I have placed an error handler. Tony Thigpen Paul Gilmartin wrote on 3/5/22 16:48: > On Mar 5, 2022, at 05:44:41, João Reginato wrote: >> >> Which is the best instruction to test if a virtual address is still valid to >> avoid an unexpected S0C4? >> > How is that information useful? > > Is its usefulness diminished by "an unexpected S0C4"? > > -- > gil
Re: Testing address validity
Using an ESPIE will avoid an ABEND, as will the appropriate use of move with key. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Keven Hall [k...@k3n.us] Sent: Saturday, March 5, 2022 6:00 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity There’s no way to avoid an ABEND unless you use FRR, ARR,ESTAE etc. or unless your thread of execution has some explicit or implicit lock on the virtual storage. There’s no “safe “ instruction that serves you purpose. The archives are replete with discussions on this topic IIRC Regards, Keven > On Mar 5, 2022, at 16:11, Tony Thigpen wrote: > > My thoughts. > > Since I support software that is called by any number of users, I would like > to validate that they provided valid parms. As a called subsystem, I can't be > messing with the callers error handling routines that may already be handling > SOC4s. I don't want to know if it's 'in storage', just that it is accessible > even if a page-fault is needed. > > I wish there was a simple: > TEST MEMORY AND BRANCH INVALID > operands R1 is a register pair with R1=address and R1+1=length to validate. > (Like an MVCL.) > > Instead of a SOC4, just branch to the address provided as the second operand > where I have placed an error handler. > > > > Tony Thigpen > > Paul Gilmartin wrote on 3/5/22 16:48: >>> On Mar 5, 2022, at 05:44:41, João Reginato wrote: >>> >>> Which is the best instruction to test if a virtual address is still valid to >>> avoid an unexpected S0C4? >>> >> How is that information useful? >> Is its usefulness diminished by "an unexpected S0C4"? >> -- >> gil
Re: Testing address validity
> How does the hardware not know the answer to that question? Because the hardware only knows about pages assigned to pages; it knows nothing about what has been paged out, as was previously noted. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Saturday, March 5, 2022 6:17 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity > only the OS knows the answer to this question Am I suffering from some mental block? How does the hardware not know the answer to that question? If an instruction can cause a S0C4, why could an instruction not answer this question? The hardware "knows" about virtual addresses. Also FWIW, I would vote for @Tony's variant, where you could ask not only about a single byte, but about a block of some specified length. Programming note 2 would have to say "the results are only valid at the instant of execution." Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dan Greiner Sent: Saturday, March 5, 2022 11:09 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity Several years ago at SHARE, I did a presentation on various requests for new architecture. Such an instruction to determine accessibility was at the top of the list. So, I dragged out an architecture instruction template and designed one on the spot: Given a base register, index register, and long displacement using a standard RXY instruction format, set a condition code to indicate whether the access caused an exception. Oh, plus programming note 1: This instruction is absolutely useless! Upon reflection, my proposed PN#1 was not totally accurate. If you happened to be running in a non-virtual environment such as OS/MFT, things would work just swell. But for any OS that uses paging to present a virtual address space to the user, only the OS knows the answer to this question. So, you need to use an OS service to make the determination. As an alternative to setting up an ESPIE environment, you might want to consider transactional execution (TX, available on the z12 and up). In addition to its multiprocessing lock elision features, TX also provides an easy means for an application to do speculative execution by evading certain program-interruption conditions. For example: TBEGIN TDB,2 JNZ ABORTED ... speculatively access data. TEND If the code branches to the ABORTED label, a transaction diagnostic block is stored (except for CC1), and the program can determine what exception condition caused the abort and whether recovery is likely without OS intervention. See the TX section of Chapter 5 for more details.
Re: Testing address validity
> only the OS knows the answer to this question Am I suffering from some mental block? How does the hardware not know the answer to that question? If an instruction can cause a S0C4, why could an instruction not answer this question? The hardware "knows" about virtual addresses. Also FWIW, I would vote for @Tony's variant, where you could ask not only about a single byte, but about a block of some specified length. Programming note 2 would have to say "the results are only valid at the instant of execution." Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dan Greiner Sent: Saturday, March 5, 2022 11:09 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity Several years ago at SHARE, I did a presentation on various requests for new architecture. Such an instruction to determine accessibility was at the top of the list. So, I dragged out an architecture instruction template and designed one on the spot: Given a base register, index register, and long displacement using a standard RXY instruction format, set a condition code to indicate whether the access caused an exception. Oh, plus programming note 1: This instruction is absolutely useless! Upon reflection, my proposed PN#1 was not totally accurate. If you happened to be running in a non-virtual environment such as OS/MFT, things would work just swell. But for any OS that uses paging to present a virtual address space to the user, only the OS knows the answer to this question. So, you need to use an OS service to make the determination. As an alternative to setting up an ESPIE environment, you might want to consider transactional execution (TX, available on the z12 and up). In addition to its multiprocessing lock elision features, TX also provides an easy means for an application to do speculative execution by evading certain program-interruption conditions. For example: TBEGIN TDB,2 JNZ ABORTED ... speculatively access data. TEND If the code branches to the ABORTED label, a transaction diagnostic block is stored (except for CC1), and the program can determine what exception condition caused the abort and whether recovery is likely without OS intervention. See the TX section of Chapter 5 for more details.
Re: Testing address validity
> Store with Caller's PSW Key There are the various "move with specified key" instructions. Best practice for writing a PC routine requires that you make use of those or equivalent services. > But would such a facility be useful to an intruder I don't think it would provide any information that would not be provided by ordinary access with an ESPIE routine. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, March 5, 2022 2:52 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity On Mar 5, 2022, at 15:11:41, Tony Thigpen wrote: > > Since I support software that is called by any number of users, I would like to validate that they provided valid parms. As a called subsystem, I can't be messing with the callers error handling routines that may already be handling SOC4s. I don't want to know if it's 'in storage', just that it is accessible even if a page-fault is needed. > Interesting problem. How do Supervisor services, which might operate in a privileged state deal with wild reply buffer addresses? Might that provide a model? I could wish for a "Store with Caller's PSW Key" instruction. (Does cross-memory services provide something similar?) Let the callers handle the damage; it's their fault. But how to provide meaningful diagnostics? > I wish there was a simple: > TEST MEMORY AND BRANCH INVALID > operands R1 is a register pair with R1=address and R1+1=length to validate. (Like an MVCL.) > > Instead of a SOC4, just branch to the address provided as the second operand where I have placed an error handler. > But would such a facility be useful to an intruder probing for a weakness to exploit?
Re: Testing address validity
There’s no way to avoid an ABEND unless you use FRR, ARR,ESTAE etc. or unless your thread of execution has some explicit or implicit lock on the virtual storage. There’s no “safe “ instruction that serves you purpose. The archives are replete with discussions on this topic IIRC Regards, Keven > On Mar 5, 2022, at 16:11, Tony Thigpen wrote: > > My thoughts. > > Since I support software that is called by any number of users, I would like > to validate that they provided valid parms. As a called subsystem, I can't be > messing with the callers error handling routines that may already be handling > SOC4s. I don't want to know if it's 'in storage', just that it is accessible > even if a page-fault is needed. > > I wish there was a simple: > TEST MEMORY AND BRANCH INVALID > operands R1 is a register pair with R1=address and R1+1=length to validate. > (Like an MVCL.) > > Instead of a SOC4, just branch to the address provided as the second operand > where I have placed an error handler. > > > > Tony Thigpen > > Paul Gilmartin wrote on 3/5/22 16:48: >>> On Mar 5, 2022, at 05:44:41, João Reginato wrote: >>> >>> Which is the best instruction to test if a virtual address is still valid to >>> avoid an unexpected S0C4? >>> >> How is that information useful? >> Is its usefulness diminished by "an unexpected S0C4"? >> -- >> gil
Re: Testing address validity
On Mar 5, 2022, at 15:11:41, Tony Thigpen wrote: > > Since I support software that is called by any number of users, I would like > to validate that they provided valid parms. As a called subsystem, I can't be > messing with the callers error handling routines that may already be handling > SOC4s. I don't want to know if it's 'in storage', just that it is accessible > even if a page-fault is needed. > Interesting problem. How do Supervisor services, which might operate in a privileged state deal with wild reply buffer addresses? Might that provide a model? I could wish for a "Store with Caller's PSW Key" instruction. (Does cross-memory services provide something similar?) Let the callers handle the damage; it's their fault. But how to provide meaningful diagnostics? > I wish there was a simple: > TEST MEMORY AND BRANCH INVALID > operands R1 is a register pair with R1=address and R1+1=length to validate. > (Like an MVCL.) > > Instead of a SOC4, just branch to the address provided as the second operand > where I have placed an error handler. > But would such a facility be useful to an intruder probing for a weakness to exploit? -- gil
Re: Testing address validity
My thoughts. Since I support software that is called by any number of users, I would like to validate that they provided valid parms. As a called subsystem, I can't be messing with the callers error handling routines that may already be handling SOC4s. I don't want to know if it's 'in storage', just that it is accessible even if a page-fault is needed. I wish there was a simple: TEST MEMORY AND BRANCH INVALID operands R1 is a register pair with R1=address and R1+1=length to validate. (Like an MVCL.) Instead of a SOC4, just branch to the address provided as the second operand where I have placed an error handler. Tony Thigpen Paul Gilmartin wrote on 3/5/22 16:48: On Mar 5, 2022, at 05:44:41, João Reginato wrote: Which is the best instruction to test if a virtual address is still valid to avoid an unexpected S0C4? How is that information useful? Is its usefulness diminished by "an unexpected S0C4"? -- gil
Re: Testing address validity
On Mar 5, 2022, at 05:44:41, João Reginato wrote: > > Which is the best instruction to test if a virtual address is still valid to > avoid an unexpected S0C4? > How is that information useful? Is its usefulness diminished by "an unexpected S0C4"? -- gil
Re: Testing address validity
Just curious would the following macros work better as a replacement for TPROT in the requested case? IARBRVER, IARBRVEA, and IARBRVKA Regards, Jeremy Schwartz From: IBM Mainframe Assembler List on behalf of Philippe Leite Sent: Saturday, March 5, 2022 9:28 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity CAUTION: This message was sent from outside the company. Do not click links or open attachments unless you recognize the sender and know the content is safe. You can use TPROT for this purpose but it's a privileged instruction. Regards, Philippe Leite LAB Services - IBM Em sáb., 5 de mar. de 2022 09:45, João Reginato escreveu: > Hi > > Which is the best instruction to test if a virtual address is still valid > to > avoid an unexpected S0C4? > > > > TIA > > João > > > --- NOTICE: This email and all attachments are confidential, may be proprietary, and may be privileged or otherwise protected from disclosure. They are intended solely for the individual or entity to whom the email is addressed. However, mistakes sometimes happen in addressing emails. If you believe that you are not an intended recipient, please stop reading immediately. Do not copy, forward, or rely on the contents in any way. Notify the sender and/or Imperva, Inc. by telephone at +1 (650) 832-6006 and then delete or destroy any copy of this email and its attachments. The sender reserves and asserts all rights to confidentiality, as well as any privileges that may apply. Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful. Please consider the environment before printing this email.
Re: Testing address validity
On Sat, 5 Mar 2022 09:44:41 -0300 João Reginato wrote: :>Which is the best instruction to test if a virtual address is still valid to :>avoid an unexpected S0C4? There have been multiple answers regarding a technique. I would question the business case for this. The obvious case is a higher authority routine (SVC/PC-supervisor state/system key eligible) accepting an address on behalf of a problem state program. The code in that case should access the storage using the key of the caller and let the chips fall where they may. Why do you care if there is an abend? If you are writing a storage snooping program, you would need to determine key if the storage can be resolved. Finally, unless the appropriate system locks (MVS) and there is proper disablement, the same query asked a few instructions later may get a different answer. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel
Re: Testing address validity
Several years ago at SHARE, I did a presentation on various requests for new architecture. Such an instruction to determine accessibility was at the top of the list. So, I dragged out an architecture instruction template and designed one on the spot: Given a base register, index register, and long displacement using a standard RXY instruction format, set a condition code to indicate whether the access caused an exception. Oh, plus programming note 1: This instruction is absolutely useless! Upon reflection, my proposed PN#1 was not totally accurate. If you happened to be running in a non-virtual environment such as OS/MFT, things would work just swell. But for any OS that uses paging to present a virtual address space to the user, only the OS knows the answer to this question. So, you need to use an OS service to make the determination. As an alternative to setting up an ESPIE environment, you might want to consider transactional execution (TX, available on the z12 and up). In addition to its multiprocessing lock elision features, TX also provides an easy means for an application to do speculative execution by evading certain program-interruption conditions. For example: TBEGIN TDB,2 JNZ ABORTED ... speculatively access data. TEND If the code branches to the ABORTED label, a transaction diagnostic block is stored (except for CC1), and the program can determine what exception condition caused the abort and whether recovery is likely without OS intervention. See the TX section of Chapter 5 for more details.
Re: Testing address validity
And I would say that ESTAE is "heavy" and is not the best choice if you expect the S0C4 with some frequency, but ESPIE is "light" and intended for this sort of thing. I remember there was some sort of VSE -- DOS/360 when I was using it -- equivalent. STXIT? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ed Jaffe Sent: Saturday, March 5, 2022 8:36 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity On 3/5/2022 7:28 AM, Philippe Leite wrote: > You can use TPROT for this purpose but it's a privileged instruction. Not only is it privileged, but it does not do what the OP has asked for. He is not concerned only about storage that happens to be paged in, he wants the answer for storage that is paged out as well. Even if such an instruction did exist, there are timing window issues -- as Charles Mills correctly pointed out. The only foolproof method is to use a recovery routine: e.g., ESPIE, ESTAE(X), ARR, FRR in z/OS or whatever equivalents exist in other operating system environments like z/VSE, z/VM, z/TPF, Linux on Z, etc. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Testing address validity
On 3/5/2022 7:28 AM, Philippe Leite wrote: You can use TPROT for this purpose but it's a privileged instruction. Not only is it privileged, but it does not do what the OP has asked for. He is not concerned only about storage that happens to be paged in, he wants the answer for storage that is paged out as well. Even if such an instruction did exist, there are timing window issues -- as Charles Mills correctly pointed out. The only foolproof method is to use a recovery routine: e.g., ESPIE, ESTAE(X), ARR, FRR in z/OS or whatever equivalents exist in other operating system environments like z/VSE, z/VM, z/TPF, Linux on Z, etc. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Testing address validity
Also, the question is somewhat unanswerable without knowing the environment. z/OS? VSE? CMS? Non-privileged program? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Charles Mills Sent: Saturday, March 5, 2022 7:40 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity I think VSMLOC may do the job for you. But all it can tell you is that the storage is allocated at the time of the VSMLOC, not what it might be a microsecond later when you access it. THE BEST thing is to set up an ESPIE and recover from any S0C4. ESPIE is lightweight. This is exactly what it is intended for. (Or SETFRR if more appropriate to your environment.) Really an IBMMAIN question. Not really about the assembler language. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of João Reginato Sent: Saturday, March 5, 2022 4:45 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Testing address validity Importance: Low Hi Which is the best instruction to test if a virtual address is still valid to avoid an unexpected S0C4?
Re: Testing address validity
I think VSMLOC may do the job for you. But all it can tell you is that the storage is allocated at the time of the VSMLOC, not what it might be a microsecond later when you access it. THE BEST thing is to set up an ESPIE and recover from any S0C4. ESPIE is lightweight. This is exactly what it is intended for. (Or SETFRR if more appropriate to your environment.) Really an IBMMAIN question. Not really about the assembler language. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of João Reginato Sent: Saturday, March 5, 2022 4:45 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Testing address validity Importance: Low Hi Which is the best instruction to test if a virtual address is still valid to avoid an unexpected S0C4?
Re: Testing address validity
You can use TPROT for this purpose but it's a privileged instruction. Regards, Philippe Leite LAB Services - IBM Em sáb., 5 de mar. de 2022 09:45, João Reginato escreveu: > Hi > > Which is the best instruction to test if a virtual address is still valid > to > avoid an unexpected S0C4? > > > > TIA > > João > > >
