https://www.ibm.com/docs/en/SSLTBW_3.1.0/pdf/ieaa900_v3r1.pdf
https://www.ibm.com/docs/en/zos/3.1.0?topic=xct-testart-tests-validity-alets BROWSE SYS1.MACLIB(TESTART) Line 0000000084 Co Command ===> Scroll *01* RETURN-CODES: * * x'00' - The specified ALET is 0. * x'04' - The specified ALET represents a valid entry on the * workunit access list. * x'08' - The specified ALET represents a valid entry on the * PASN access list. * x'0C' - The specified ALET is 1. * x'10' - The specified ALET/EAX will result in invalid ART * exceptions. * x'14' - An unexpected error occurred in the service routine, * IEAVXTAR. * x'18' - The specified ALET represents a valid CADS ALET. Jim Mulder -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Binyamin Dissen Sent: Wednesday, June 4, 2025 1:53 AM To: [email protected] Subject: Re: Seerms like TAR requires AR mode Both SA23-1370-50 (2.5) and SA23-1370-60 (3.1) state 08 Meaning: The specified ALET represents a valid entry on the DU-AL. If CADS=YES was specified on the call, the ALET does not point to an entry for a SCOPE=COMMON data space. Action: None required. However, you might take some action based upon your application. Which manual do you have? On Wed, 4 Jun 2025 01:37:54 +0000 James Mulder <[email protected]> wrote: :> You are getting the correct result. Your ALET is on the PASN access list, and you are getting return code 8, for which the documentations says: :> :>Meaning: The specified ALET represents a valid entry on the PASN-AL. :> :>Action: None required. However, you might take some action based upon your application. :> :> The documentation you are quoting is for return code 4. :> :> :>Jim Mulder :> :>-----Original Message----- :>From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Binyamin Dissen :>Sent: Tuesday, June 3, 2025 2:37 PM :>To: [email protected] :>Subject: Re: Seerms like TAR requires AR mode :> :>Looks like the return code of TESTART is not correct (or I am misunderstanding :>something): :> :>The TESTART expands to :> :>+ TAR AR3,1 :>+ LA 15,4(0,0) :>+ BRC 4,IHB1242K (BC) :>+ LA 15,0(0,0) :>+ BRC 8,IHB1242K (BC) :>+ LA 15,8(0,0) <<<==== :>+ BRC 2,IHB1242K (BC) <<<==== :> :>TAR: 2 - ALET designates the primary-space access list and does not cause exceptions in ART :> :>TESTART: 08 - Meaning: The specified ALET represents a valid entry on the DU-AL. If CADS=YES was specified on the call, the ALET does not point to an entry for a SCOPE=COMMON data space. :> :>I am getting R15=8. The ALET is, in fact, in the PASN (begins with 01). :> :>Am I missing something obvious? :> :>On Tue, 3 Jun 2025 16:58:14 +0000 James Mulder <[email protected]> wrote: :> :>:>Correcting to add a missing word "is" :>:> :>:>I would anticipate that if you looked at systrace in a dump taken after you successfully used the ALET after getting a CC3 from TAR, you would see a PGM 02B (if this was a data space reference) or a PGM 02C (if this was an address space reference when you used the ALET. Recognizing the cases when the z/OS program check handler will resolve these exceptions and return to the program is the part of what TESTART would add that is of interest in your case. :>:> :>:> I will also add my recollection of how the TESTART macro came to be (as much as my memories from 38 years ago can be trusted). :>:> :>:> During the testing of MVS/ESA SP3.1.0, some MVS test cases using the TAR instruction were failing intermittently due to unexpected CC3. After some investigation, there was an "oh crap, the TAR instruction cannot provide all of the function that we intended" moment. And that resulted in the :>:>creation of the TESTART macro and the IEAVXART PC routine. If you look in the change activity in the TESTART macro, you will see :>:> :>:>$D0=DCR0277 HBB3310 870831 PD162M: TESTART macro :> :>:>DCR was an acronym for Design Change Request (typically used for something that was not part of the original FPFS (Final Programming Functional Specification)) for the release. :>:> :>:>Jim Mulder :>:> :>:>-----Original Message----- :>:>From: James Mulder :>:>Sent: Tuesday, June 3, 2025 12:23 PM :>:>To: IBM Mainframe Discussion List <[email protected]> :>:>Subject: RE: Seerms like TAR requires AR mode :> :> I would anticipate that if you looked at systrace in a dump taken after you successfully used the ALET after getting a CC3 from TAR, you would see a PGM 02B (if this was a data space reference) or a PGM 02C (if this was an address space reference when you used the ALET. Recognizing the cases when the z/OS program check handler will resolve these exceptions and return to the program the part of what TESTART would add that is of interest in your case. :>:> :>:> I would guess that Principles of Operation is correct, and that the reason that "So I did the SAC 512 before the TAR and all of a sudden I got the expected CC." is that in between your CC3 and your expected CC, you used the ALET and caused the PGM 02B or PGM 02C, and the program check handler resolved the exception so that your next TAR (regardless of the ASC mode) got the CC that you expected. :>:> :>:>Jim Mulder :>:> :>:>-----Original Message----- :>:>From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Binyamin Dissen :>:>Sent: Tuesday, June 3, 2025 12:01 PM :>:>To: [email protected] :>:>Subject: Re: Seerms like TAR requires AR mode :> :>My use is to determine if an ALET that I added is still valid. Obviously my RESMGR should pick up if the target address space (non-swapable) goes away, but I am a great believer in belt and suspenders. Not obvious to me what TESTART would add. :>:> :>:>But, at any rate, is the POPs description incorrect and is AR mode required (as my experience shows)? :>:> :>:> :>:>.On Tue, 3 Jun 2025 15:23:15 +0000 James Mulder <[email protected]> wrote: :>:> :>:>:> On z/OS, the TAR instruction is not useful by itself. You should instead use the TESTART macro, which PCs to the operating system to analyze a CC3 from the TAR instruction. :>:>:> :>:>:>Jim Mulder :>:>:> :>:>:>-----Original Message----- :>:>:>From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Binyamin Dissen :>:>:>Sent: Tuesday, June 3, 2025 1:53 AM :>:>:>To: [email protected] :>:>:>Subject: Re: Seerms like TAR requires AR mode :> :>On Mon, 2 Jun 2025 18:14:58 -0400 Tony Harminc <[email protected]> wrote: :>:>:> :>:>:>:>On Mon, 2 Jun 2025 at 17:48, Binyamin Dissen < :>[email protected]> wrote: :>:>:> :>:>:>:>> The doc for TAR states :>:>:> :>:>:>:>> "The operation does not depend on the translation mode - bits 5, 16, and :>> 17 of :>> the PSW are ignored." :>:>:> :>:>:>:>> But when I issue it in primary mode I am getting CC=3 but when in AR mode :>> the :>> expected condition code. :>:>:> :>:>:>:>You've been around long enough to know how unlikely it is that the :>implementation on your machine differs from the PofO. Not impossible, :>certainly, but very very unlikely. Maybe a bit more likely on a zPDT, but :>even there they've done a very good job, and presumably have much the same :>tools and test cases as the Real Iron people have. :>:>:> :>:>:>The machine is an 8561. :>:>:> :>:>:>As I have been around long enough, I already did the investigations. I ignored the CC=3 and used the ALET and all was fine. :>:>:> :>:>:>So I did the SAC 512 before the TAR and all of a sudden I got the expected CC. :>:>:> :>:>:>It might be kind of strange to try the TAR in primary as the ALET is unused in that mode, but as the code was running PRIMARY and would only need AR if the ALET was good, I deferred the switch. :>:>:> :>:>:> :>:>:>:>So... SLIP (or whatever) and look at your registers, ARs, etc. for both :>cases. It is a bit annoying that there doesn't seem to be a way to see :>exactly which exception caused the CC=3, but I'm betting you'll find some :>difference in your regs or ARs. :>:>:> :>:>:>Already confirmed. -- Binyamin Dissen <[email protected]> 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
