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
