I had always thought (assumed?) that when IBM changes a manual, they changes the manual number, i.e., SA23-1370-60 to SA23-1370-61
This is kind of scary. You periodically check the checksum of the manuals to see if there were changes? On Wed, 4 Jun 2025 12:07:50 -0400 Mike Shaw <[email protected]> wrote: :>We review a LOT of IBM publications in our work. There are many many cases :>where doc changes are made and are NOT noted in the manual. It seems to be :>an artifact of the 'continuous deliver' method of doc delivery used on the :>IBM doc web site now. :> :>Mike Shaw :>MVS/QuickRef Support Group :>Chicago-Soft, Ltd. :> :> :>On Wed, Jun 4, 2025 at 11:24?AM Binyamin Dissen < :>[email protected]> wrote: :> :>> Very interesting. :>> :>> The SA23-1370-60 that I have is dated 2023-09-24 while your link is dated :>> 2024-10-28. :>> :>> No change to the manual number. :>> :>> Nothing in the "Summary of Changes" regarding TESTART. :>> :>> No change bars. :>> :>> Just 04 and 08 are flipped. :>> :>> On Wed, 4 Jun 2025 14:10:55 +0000 James Mulder <[email protected]> wrote: :>> :>> :>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 -- 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
