Transaction dump requires IPCS as well it’s unformatted seems restricted to one address space
> On Apr 3, 2023, at 1:28 PM, Seymour J Metz <sme...@gmu.edu> wrote: > > Have you considered writing a message in a transaction dump? > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of > Joseph Reichman <reichman...@gmail.com> > Sent: Monday, April 3, 2023 11:37 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Calling SVC 51 > > I got the snap(x) to work dumping the data space owned by another address > space > > For my snap(x) dataset I was able to write messages > In my recovery where the program abended > And registers > > Just wondering if I can do this with a sdump(x) > > I know the dcb is RECFM=FB and lrecl=4160 > >> On Apr 3, 2023, at 8:48 AM, reichman...@gmail.com wrote: >> >> I know >> >> I wrote a generic dump routine >> >> If first flag byte +1 of the parm list bit0 is 0 its snap(x) NOT sdumpx >> >> I am trying to dump a dataspace created in a SRB in another address space >> the doc says I should be able to do it with snapx >> >> Here is the doc >> >> Use the DSPSTOR parameter on the SNAPX macro to dump storage from any data >> space that the caller has addressability to, providing the program also has >> a TCB key (for SCOPE=SINGLE and SCOPE=ALL data spaces) or a PSW key (for a >> SCOPE=COMMON data space) that matches the storage key of the data space. >> >> As it was created with SCOPE=ALL >> >> I would rather use SNAPX because it easier for me to look in ISPF browse the >> IPCS >> thanks >> -----Original Message----- >> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of >> Peter Relson >> Sent: Monday, April 3, 2023 8:27 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Calling SVC 51 >> >> If by "calling SVC 51" you mean "issuing SNAP(X)", we can continue. SVC 51 >> is used for multiple purposes. >> >> Use the DCB attributes that are documented or don't bother playing. >> >> <snip> >> I am trying to dump a dataspace (that is owned by an other address space) >> SNAPX doc says "The system dumps storage from any data space to which the >> caller has authority" I interpret this to mean that the ALET is on my DU-AL >> </snip> >> >> That is not the right interpretation. You have access to spaces represented >> by entries on your DU-AL, your PASN-AL, or a common area data spaces. In all >> cases, you would not have access to an entry marked "private" unless you >> have a matching EAX. >> >> SNAP(X) provides information only for data accessible from your address >> space (whether because it is part of the address space or is accessible by a >> suitable access list). >> >> Further, if the dataspace is "owned by another address space", it can be >> risky to add it to "your" access list. >> >> 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 > > > ---------------------------------------------------------------------- > 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
