I don't know anything about how access lists are using in operating systems other than z/OS, so I can't speak for them.
I will forward this discussion to architecture to consider whether a Programming Note about z/OS would be appropriate. Jim Mulder -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Binyamin Dissen Sent: Tuesday, June 3, 2025 2:16 PM To: [email protected] Subject: Re: Seerms like TAR requires AR mode Did some deeper testing and the results are inconsistent, i.e., sometimes primary gets the proper CC and sometimes AR mode gets CC=3. So I guess that matches your testing. Which OS's get consistent results from TAR? VSE? Linux? Should the POPs have a warning? 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
