Re: Traversing The Linkage Stack
Peter By you pointing out that the entry descriptor Was at the end of the linkage stack you were able to locate my error As I assumed that STCBLSDP which points to the entry descriptor was also the begging point of the linkage stack but it was not Thank you for your help > On Jan 15, 2024, at 4:22 PM, Peter Relson > <056a472f7cb4-dmarc-requ...@listserv.ua.edu> wrote: > > Joe R wrote > I got to a X'89' is a header the doc say that decrementing that would > bring to a new linkage frame I specifically remember looking - 32 bytes from > there and it was all zeros. > > Not having ready access to that document, but knowing who wrote it, I'll bet > that it does not say that. It certainly isn't true architecturally. > > You might look again at the architectural definition of the header stack > entry (which I expect that that presentation shows correctly). > Is it actually the case that you had only the one BAKR entry on the linkage > stack and that is why the preceding entry descriptor was for the header? If > so, of course there is nothing preceding that, which the rest of the > information in that entry descriptor would have indicated. > > I don't recall that you ever posted what the linkage stack looked like (you > showed only the entry descriptor and data that actually was irrelevant > because it was part of the next entry). If true, despite being asked about > doing so, why not? You misinterpreted data that you did not let the readers > see, made incorrect conclusions and started with that. Really? What can we do > to get you to post in a meaningful and useful way so that the kind readers of > IBM-Main can help (without wasting unnecessary time)? > > Peter Relsonz/OS Core Technology Design > > > > Peter Relsonz/OS Core Technology Design > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Traversing The Linkage Stack
Joe R wrote I got to a X'89' is a header the doc say that decrementing that would bring to a new linkage frame I specifically remember looking - 32 bytes from there and it was all zeros. Not having ready access to that document, but knowing who wrote it, I'll bet that it does not say that. It certainly isn't true architecturally. You might look again at the architectural definition of the header stack entry (which I expect that that presentation shows correctly). Is it actually the case that you had only the one BAKR entry on the linkage stack and that is why the preceding entry descriptor was for the header? If so, of course there is nothing preceding that, which the rest of the information in that entry descriptor would have indicated. I don't recall that you ever posted what the linkage stack looked like (you showed only the entry descriptor and data that actually was irrelevant because it was part of the next entry). If true, despite being asked about doing so, why not? You misinterpreted data that you did not let the readers see, made incorrect conclusions and started with that. Really? What can we do to get you to post in a meaningful and useful way so that the kind readers of IBM-Main can help (without wasting unnecessary time)? Peter Relsonz/OS Core Technology Design Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Traversing The Linkage Stack Peter thanks
Found it Part of the problem was in TEST I was doing a list the SDWAEC2 had 0704 while the Linkage stack 070C But the reason for that was bit 12 is on for 8 byte PSW and off as in the linkage stack for 16 byte PSW -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Saturday, January 13, 2024 10:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Traversing The Linkage Stack >From one of the posts, it wasn't clear if the OP realized that the entry >descriptor is at the end of the entry, not at the beginning. If you're not traversing stack sections, complications related to header and trailer don't tend to come into play. Consider posting the entire linkage stack from start through time of error, along with the data from the SDWA which the OP indicates is not in the linkage stack. Unlike AI, RTM does not make stuff up. If there is a PSW, RTM found it somewhere, either in an RB/XSB or the linkage stack. If there is a problem marking the PSW as "from a linkage stack entry", that would be good to know. And for that, the information I mentioned above (plus all the data from the RBs/XSBs) would be needed for diagnosis. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Traversing The Linkage Stack
Thank you. You are correct in my error however I do remember that I what I used as a starting point was STCBLSDP and from memory it pointed to a X'8C' which is branch state entry. Regardless bumping down by X'128' I got to a X'89' is a header the doc say that decrementing that would bring to a new linkage frame I specifically remember looking - 32 bytes from there and it was all zeros. I am using the 2012 Share PDF Titled "DUAL Address Space and Linkage-Stack Architecture." Peter I Am not asking you to reveal IBM secrets. But in the traversing the linkage stack can I still use that as a guide Thank you. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Saturday, January 13, 2024 10:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Traversing The Linkage Stack >From one of the posts, it wasn't clear if the OP realized that the entry >descriptor is at the end of the entry, not at the beginning. If you're not traversing stack sections, complications related to header and trailer don't tend to come into play. Consider posting the entire linkage stack from start through time of error, along with the data from the SDWA which the OP indicates is not in the linkage stack. Unlike AI, RTM does not make stuff up. If there is a PSW, RTM found it somewhere, either in an RB/XSB or the linkage stack. If there is a problem marking the PSW as "from a linkage stack entry", that would be good to know. And for that, the information I mentioned above (plus all the data from the RBs/XSBs) would be needed for diagnosis. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Traversing The Linkage Stack
>From one of the posts, it wasn't clear if the OP realized that the entry >descriptor is at the end of the entry, not at the beginning. If you're not traversing stack sections, complications related to header and trailer don't tend to come into play. Consider posting the entire linkage stack from start through time of error, along with the data from the SDWA which the OP indicates is not in the linkage stack. Unlike AI, RTM does not make stuff up. If there is a PSW, RTM found it somewhere, either in an RB/XSB or the linkage stack. If there is a problem marking the PSW as "from a linkage stack entry", that would be good to know. And for that, the information I mentioned above (plus all the data from the RBs/XSBs) would be needed for diagnosis. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Traversing The Linkage Stack
It’s 2012 Thanks > On Jan 10, 2024, at 2:45 PM, Tom Marchant > <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > > I'm pretty sure that nothing about the way MVS works with the Linkage Stack > is a programming interface. > > How old is that presentation you are using? The Linkage Stack changed > significantly with z/Architecture. > The definitive documentation is the Principles of Operation. > > If you want to learn about the structure of the Linkage stack, issue several > BAKR instructions and abend. > Use IPCS to process the resulting SYSMDUMP. > Look at the formatted linkage stack entries in the dump and compare that to > storage. > > -- > Tom Marchant > >> On Wed, 10 Jan 2024 10:18:42 -0500, Joseph Reichman >> wrote: >> >> Hi >> >> I am using a share PDF as a guide "Dul Address Space & Linkage Stack" as >> guide to looking thru a WU Linkage Stack >> >> In the case of a TCB I believe the current is pointed to by STCBLSDP >> >> This is I understand it points to the header of which there four different >> types each of X'128' bytes in Length >> >> Header looking the zone portion of the first byte 1001 or 9 >> Trailer 1010 or A >> Branch Entry C >> PC entry D >> >> In the case of header in order to calculate the address of the next stack it >> would be header - 4 >> >> When I get a X'89' the 8 being the stack suppression bit - 4, -16 , or >> even -32 from the header is all zeros >> >> >> Thank you >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Traversing The Linkage Stack
I'm pretty sure that nothing about the way MVS works with the Linkage Stack is a programming interface. How old is that presentation you are using? The Linkage Stack changed significantly with z/Architecture. The definitive documentation is the Principles of Operation. If you want to learn about the structure of the Linkage stack, issue several BAKR instructions and abend. Use IPCS to process the resulting SYSMDUMP. Look at the formatted linkage stack entries in the dump and compare that to storage. -- Tom Marchant On Wed, 10 Jan 2024 10:18:42 -0500, Joseph Reichman wrote: >Hi > >I am using a share PDF as a guide "Dul Address Space & Linkage Stack" as >guide to looking thru a WU Linkage Stack > >In the case of a TCB I believe the current is pointed to by STCBLSDP > >This is I understand it points to the header of which there four different >types each of X'128' bytes in Length > >Header looking the zone portion of the first byte 1001 or 9 >Trailer 1010 or A >Branch Entry C >PC entry D > >In the case of header in order to calculate the address of the next stack it >would be header - 4 > >When I get a X'89' the 8 being the stack suppression bit - 4, -16 , or >even -32 from the header is all zeros > > >Thank you > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
