We very often know there were changes, but the "Changes" section near the front of the PDF file just as often does not identify what the changes were. Going through the PDF page by page can help spot the "change" bars in the left margin, but that is not foolproof either.
It is not like the old days where changes were clearly marked and direct feedback to the author of that pub was possible. Mike On Thu, Jun 5, 2025, 3:34 AM Binyamin Dissen < [email protected]> wrote: > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
