Thanks > On Apr 3, 2023, at 3:32 PM, Seymour J Metz <[email protected]> wrote: > > PROBDESCAD=probdescad > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Discussion List [[email protected]] on behalf of > Tony Harminc [[email protected]] > Sent: Monday, April 3, 2023 3:14 PM > To: [email protected] > Subject: Re: Calling SVC 51 > >> On Mon, 3 Apr 2023 at 13:41, Joseph Reichman <[email protected]> wrote: >> >> Transaction dump requires IPCS as well it’s unformatted seems restricted to >> one address space > > I'm confused. The result of SDUMP is also unformatted, hence that 4160 > FBS (don't forget the "S"). > > (I shouldn't call it "unformatted"; it's not formatted for people to > read, but the dump records in those blocks are mapped by a strangely > nested set of macros starting with AMDDATA or BLSRPRD if you prefer, > so it's certainly structured and mostly documented data.) > > So where, i.e. in what kind of record, would any message you want to > write actually go? > > Tony H. > >>>> On Apr 3, 2023, at 1:28 PM, Seymour J Metz <[email protected]> wrote: >>> >>> Have you considered writing a message in a transaction dump? >>> >>> ________________________________________ >>> From: IBM Mainframe Discussion List <[email protected]> on behalf of >>> Joseph Reichman <[email protected]> >>> Sent: Monday, April 3, 2023 11:37 AM >>> To: [email protected] >>> 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, [email protected] 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 <[email protected]> On Behalf Of >>>> Peter Relson >>>> Sent: Monday, April 3, 2023 8:27 AM >>>> To: [email protected] >>>> 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 [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 >>> >>> >>> ---------------------------------------------------------------------- >>> 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 > > ---------------------------------------------------------------------- > 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
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
