Off the top of my head, maybe the problem state program has been called by another program running on another TCB and part of the parameter list is the ALET for a structure that the called program will process. TAR could help the called program validate the ALET and perform early rejections via RC+RSN rather than catching an abend.
Obviously you could use normal abend recovery for this as well, but why deny the use of TAR to problem state callers if there is no good reason to? TAR also has a condition code to indicate an ALET of hex zero (which might be handy to discover as part of this single instruction). Somebody, somewhere is making use of TAR in problem state code and is happy about it. 🙂 Rob Scott Rocket Software ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Binyamin Dissen <[email protected]> Sent: 14 January 2025 12:03 PM To: [email protected] <[email protected]> Subject: Re: Use of TAR to test access register validity EXTERNAL EMAIL Granted all that. My query is what would a problem state program do if it discovers that the ALET provided is bad? It is not like system level software where something goes away in another address space where you might decide to dispose of an item on a queue. Unless there is something functional that can be done, why check? The abend dump will certainly help in diagnosing the problem. Brings back memories of an MVS program that checked if it was running under MVS (IIRC a CVT bit). If it wasn't, what could it do about it? On Tue, 14 Jan 2025 10:26:27 +0000 Rob Scott <[email protected]> wrote: :>A problem state program can validly create and use a SCOPE=SINGLE dataspace , so the ability to test an AR via TAR is valid in that environment. :> :>Perhaps having an ESTAE(X) and catching any 0C4 abends would be better in some circumstances, but there is nothing inherently wrong with using TAR. :> :>Rob Scott :>Rocket Software :> :>________________________________ :>From: IBM Mainframe Discussion List <[email protected]> on behalf of Binyamin Dissen <[email protected]> :>Sent: 14 January 2025 7:54 AM :>To: [email protected] <[email protected]> :>Subject: Re: Use of TAR to test access register validity :> :>EXTERNAL EMAIL :> :> :> :> :>An AX value of zero will check whether the current DU has access. :> :>But I would question why the application level code is checking the AR. :> :>How did it get it? :> :>What does the AR being invalid mean to the program, i.e., what corrective :>action will be taken? :> :>If it is a PASN qualified ALET, the TAR results are only true now, but may be :>different at the next instruction. :> :>Why not simply get the 0C4 type failure if the ALET is bad? :> :>On Tue, 14 Jan 2025 01:38:34 -0600 John Dravnieks :><[email protected]> wrote: :> :>:>Hello :>:> :>:>I have come across some usage of the Test Access instruction (TAR) in a problem state program - given that TAR is documented in Chapter 10 of Pop (usually the supervisor state instructions generally only of use to the operating system) I am concerned that TAR is being used incorrectly :>:> :>:>The code correctly loads an access register into AR7 and then has this: :>:> TAR R7,R0 Valid access register? :>:> JP AOK Yes :>:> :>:>The second operand R0 refers to general register 0, which has a positive value of 32768 or less - so bits 32-47 of gpr0 will be zero so the effective EAX used by TAR will be zero. :>:> :>:>My question is is this a valid way to test the validity of an access register? And should it also be checking for a condition code of 1 as well ? :>:> :>:>Kind regards :>:>John Dravnieks, 21CS Software :>:>(posted here at suggestion of Binyamin Dissen) :>:> :>:>---------------------------------------------------------------------- :>:>For IBM-MAIN subscribe / signoff / archive access instructions, :>:>send email to [email protected] with the message: INFO IBM-MAIN -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com<http://www.dissensoftware.com> Director, Dissen Software, Bar & Grill - Israel ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ================================ Rocket Software, Inc. and subsidiaries ■77 Fourth Avenue, Waltham MA 02451 ■Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy ================================ This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
