Re: Reading a dump
Agreed! Especially if you compile with GONUM. Sometimes, you do need to dig a bit deeper. For this I use Fault Analyzer which has a fastly superior UI compared to IPCS. I only crack open IPCS when I need to format control blocks or read the systrace. On 2020-06-22 1:08 AM, Charles Mills wrote: +1 !!! Look at the LE or C runtime options books and get yourself a CEEDUMP. Debugging from one is a little bit of a learning exercise of its own but FAR superior to SYSUDUMP for 9 out of 10 (or perhaps 99 out of 100) C runtime errors. You will get the exact line number of the offending source statement, and the call trace of how you got there, perhaps some relevant variables, and a hex dump of the field that gave you the S0C4 (although that last one may require a little looking). Purists may object. Yeah, if you are a hardcore MVS debugger, go for it with IPCS. (But if the OP were a hardcore MVS debugger, he would not have written the query that he did.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Don Poitras Sent: Sunday, June 21, 2020 3:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Reading a dump Since the program is written in C, SYSUDUMP really isn't the easiest place to look for info. CEEDUMP will show the regs and a traceback which is usually all that's needed. See TERMTHDACT option for how to generate a CEEDUMP. -- 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: Reading a dump
Thank you all I am looking at your suggestions, but the issue was not really the dump but how I compile and bind the thing. I am away from our beloved z/OS most of the time, but with your help I figure it out. Ze'ev -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dfdss equivalent to fdr map
[Default] On 20 Jun 2020 19:33:23 -0700, in bit.listserv.ibm-main haresystemssupp...@comcast.net (Tim Hare) wrote: >Question: does it really matter with a volume that's a virtual thing >implemented on a RAID array? Number of extents still would matter. Also if the data set was allocated in tracks rather than cylinders there could bee more end of extent checking. Clark Morris > >-- >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: Reading a dump
> nice SYSUDUMP At least it wasn't SYSABEND! I find that large formatted dumps are awkward and that it's easier to find things with IPCS. Also, when LE and other run-time libraries use SPIE and STAE, the footprints can be easier to find in a CEEDUMP or SYSMDUMP. Gneiss is often taken for granite. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Ze'ev Atlas [004b34e7c98a-dmarc-requ...@listserv.ua.edu] Sent: Friday, June 19, 2020 6:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Reading a dump I admit that I am rusty and did not look at any dump for decades, and when I did I was coding either Assembler or COBOL and I knew how to decipher the thing.I am porting a C library libxc to classic z/OS and it compiles cleanly (most of it, at least). As is implied by the description, most users of that thing are running it on Linux or Windows. Maybe a few on Unix machines. I tried to run its modules on my z/OS machine (genuine IBM, z/OS 2.4), and I get S0C4, with nice SYSUDUMP! I have no idea how to begin to look and I am afraid that I compiled it with wrong options. Is there any C maven in the audience that could please try to guide me where to begin looking. I tried to avoid compiling it as dll (that much I sort of knew) but I am not sure any more. Ze'ev Atlas -- 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: Allocating GDG(+1) using SVC 99
Side note: I had to chuckle when I first saw "NDM" replaced in all the messages and screens with "C:D". Hey, a 3 character replace and we're done without having to worry about strings getting longer or shorter :) On 6/21/2020 10:24 AM, Steve Thompson wrote: Managed File Transfer. NDM, is one (aka Connect:Direct). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocating GDG(+1) using SVC 99
Managed File Transfer. NDM, is one (aka Connect:Direct). The other stuff was caused/created by SMS. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Jun 21, 2020, at 12:41 PM, Seymour J Metz wrote: > > There was no SVC 99 in MFT. SVC 99 (very different from the one you know and > love) was part of TSO, an MVT only option. And "Roll In/Roll Out" had nothing > to do with GDGs; don't ask, don't tell. > > WRT cataloging, it depends on whether it's an SMS volume; for non-SMS, > cataloging is done at deallocation time. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Steve Thompson [ste...@copper.net] > Sent: Sunday, June 21, 2020 9:33 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Allocating GDG(+1) using SVC 99 > > From MFT days SVC99 alloc in a JOB is not treated the same as INIT ALLOC > (JCL). It has been a while since I’ve had to know this stuff and memory gets > hazy. Throw in VTS and there may be nuances that I’ve not been exposed to. > > “Roll in” occurs when you dealloc when doing SVC99. > > If using TAPE, Catalog is effectively done at dealloc not at allocation as it > is with DASD. > > Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct > mistaks > > >> On Jun 21, 2020, at 9:20 AM, Joseph Reichman wrote: >> >> Going to to try it now but it seems logical that the system updates it ( >> the relative number after the dataset is unallocated ) >> As from what I remember in multi step job >> Where the GDG is explicitly allocated the GDG number gets updates only after >> completion of the entire job >> >> Thanks >> >> >> On Jun 21, 2020, at 5:56 AM, Binyamin Dissen wrote: >>> >>> On Sun, 21 Jun 2020 01:02:41 -0400 Joseph Reichman >>> wrote: >>> >>> :>I am doing a number of snapx type dumps in a started task. I would like to >>> :>keep each and every one in a separate dsn. It would seem keeping them in a >>> :>GDG would accomplish this. >>> >>> :>The Documentation says that If I turn on S99GDGNT in S99FLAG1 I could >>> :>specify the dsn as MYSDUMP.GDG(+1) and have each snap dump in a separate >>> :>providing I do a close un allocate as a text unit (meaning I would >>> :>unallocated the dataset upon closing the snap file). >>> >>> :>If I read documentation right it seems that upon a close unallocate the >>> :>relative gag number gets updated >>> >>> It would seem to not require any free. Why haven't you tried it? >>> >>> -- >>> Binyamin Dissen >>> http://secure-web.cisco.com/16f5MZFgg2VcKAwferkHfKJZm0TgMKh5SGRCQrzb__z8zeZDoncu7dybqqYo73PicmxjngnoW65yVsVUG8QIOrIRSeS1a7S3FCznpVHyMlmI9f3O53dErFbu1pdJL-oVyJk1FMHafvEa7ZQYPqkBit7VE-WlH_ScZRHXceyerSgteLe95Q5SIbqELEae1zRYROCFmIA7TFD3b96nRJsGltTfpoR5Mc7TKKWTKy2p6PQF8RbC1qwL1JiIuZs-tzpuJSt0JORzaRGKzegEF1gYJWC_52B6w-j5tj8oD6RMqzCdq0NxFzvrsXIfltNJ0ZsfLZxNObkdVuCcgcL24TSo9zuOqwmv8R4FH8kSdVyE4P6k7oAzFXWsCCiQEWhoSsA_91BUSLwEYxAlpWyGbBqP_fk-ZIxoEymnp5x98GlYpviv4maSS-tdteAo-ayuQ3tEM/http%3A%2F%2Fwww.dissensoftware.com >>> >>> Director, Dissen Software, Bar & Grill - Israel >>> > > -- > 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: Reading a dump
+1 !!! Look at the LE or C runtime options books and get yourself a CEEDUMP. Debugging from one is a little bit of a learning exercise of its own but FAR superior to SYSUDUMP for 9 out of 10 (or perhaps 99 out of 100) C runtime errors. You will get the exact line number of the offending source statement, and the call trace of how you got there, perhaps some relevant variables, and a hex dump of the field that gave you the S0C4 (although that last one may require a little looking). Purists may object. Yeah, if you are a hardcore MVS debugger, go for it with IPCS. (But if the OP were a hardcore MVS debugger, he would not have written the query that he did.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Don Poitras Sent: Sunday, June 21, 2020 3:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Reading a dump Since the program is written in C, SYSUDUMP really isn't the easiest place to look for info. CEEDUMP will show the regs and a traceback which is usually all that's needed. See TERMTHDACT option for how to generate a CEEDUMP. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocating GDG(+1) using SVC 99
There was no SVC 99 in MFT. SVC 99 (very different from the one you know and love) was part of TSO, an MVT only option. And "Roll In/Roll Out" had nothing to do with GDGs; don't ask, don't tell. WRT cataloging, it depends on whether it's an SMS volume; for non-SMS, cataloging is done at deallocation time. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Thompson [ste...@copper.net] Sent: Sunday, June 21, 2020 9:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Allocating GDG(+1) using SVC 99 From MFT days SVC99 alloc in a JOB is not treated the same as INIT ALLOC (JCL). It has been a while since I’ve had to know this stuff and memory gets hazy. Throw in VTS and there may be nuances that I’ve not been exposed to. “Roll in” occurs when you dealloc when doing SVC99. If using TAPE, Catalog is effectively done at dealloc not at allocation as it is with DASD. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Jun 21, 2020, at 9:20 AM, Joseph Reichman wrote: > > Going to to try it now but it seems logical that the system updates it ( the > relative number after the dataset is unallocated ) > As from what I remember in multi step job > Where the GDG is explicitly allocated the GDG number gets updates only after > completion of the entire job > > Thanks > > > >> On Jun 21, 2020, at 5:56 AM, Binyamin Dissen >> wrote: >> >> On Sun, 21 Jun 2020 01:02:41 -0400 Joseph Reichman >> wrote: >> >> :>I am doing a number of snapx type dumps in a started task. I would like to >> :>keep each and every one in a separate dsn. It would seem keeping them in a >> :>GDG would accomplish this. >> >> :>The Documentation says that If I turn on S99GDGNT in S99FLAG1 I could >> :>specify the dsn as MYSDUMP.GDG(+1) and have each snap dump in a separate >> :>providing I do a close un allocate as a text unit (meaning I would >> :>unallocated the dataset upon closing the snap file). >> >> :>If I read documentation right it seems that upon a close unallocate the >> :>relative gag number gets updated >> >> It would seem to not require any free. Why haven't you tried it? >> >> -- >> Binyamin Dissen >> http://secure-web.cisco.com/16f5MZFgg2VcKAwferkHfKJZm0TgMKh5SGRCQrzb__z8zeZDoncu7dybqqYo73PicmxjngnoW65yVsVUG8QIOrIRSeS1a7S3FCznpVHyMlmI9f3O53dErFbu1pdJL-oVyJk1FMHafvEa7ZQYPqkBit7VE-WlH_ScZRHXceyerSgteLe95Q5SIbqELEae1zRYROCFmIA7TFD3b96nRJsGltTfpoR5Mc7TKKWTKy2p6PQF8RbC1qwL1JiIuZs-tzpuJSt0JORzaRGKzegEF1gYJWC_52B6w-j5tj8oD6RMqzCdq0NxFzvrsXIfltNJ0ZsfLZxNObkdVuCcgcL24TSo9zuOqwmv8R4FH8kSdVyE4P6k7oAzFXWsCCiQEWhoSsA_91BUSLwEYxAlpWyGbBqP_fk-ZIxoEymnp5x98GlYpviv4maSS-tdteAo-ayuQ3tEM/http%3A%2F%2Fwww.dissensoftware.com >> >> Director, Dissen Software, Bar & Grill - Israel >> -- 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: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET
On Sat, 20 Jun 2020 18:09:35 -0500, Walt Farrell wrote: > >Time Of Check To Time Of Use. As you're making the check, a security >administrator might be changing the rules. Your program might end up getting a >false positive or false negative. >... >It is much simpler, and safer, and in general more robust, to simply issue the >OPEN in the proper program environment and let the system say Yes or No. > As strongly as I agree with that, a programmer might have a sincere wish to avoid the side effects of a prior operation. Suppose a job successfully allocates GDG(+1) then access to another data set fails. The job does nothing useful but the generation is incremented. That programmer wishes, ideally, that the initiator could verify access permissions for all resources mentioned in JCL in the same atomic operation in which it obtains ENQs. But it's not realistic to wish for Logical Unit of Work encapsulation of batch jobs. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocating GDG(+1) using SVC 99
From MFT days SVC99 alloc in a JOB is not treated the same as INIT ALLOC (JCL). It has been a while since I’ve had to know this stuff and memory gets hazy. Throw in VTS and there may be nuances that I’ve not been exposed to. “Roll in” occurs when you dealloc when doing SVC99. If using TAPE, Catalog is effectively done at dealloc not at allocation as it is with DASD. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Jun 21, 2020, at 9:20 AM, Joseph Reichman wrote: > > Going to to try it now but it seems logical that the system updates it ( the > relative number after the dataset is unallocated ) > As from what I remember in multi step job > Where the GDG is explicitly allocated the GDG number gets updates only after > completion of the entire job > > Thanks > > > >> On Jun 21, 2020, at 5:56 AM, Binyamin Dissen >> wrote: >> >> On Sun, 21 Jun 2020 01:02:41 -0400 Joseph Reichman >> wrote: >> >> :>I am doing a number of snapx type dumps in a started task. I would like to >> :>keep each and every one in a separate dsn. It would seem keeping them in a >> :>GDG would accomplish this. >> >> :>The Documentation says that If I turn on S99GDGNT in S99FLAG1 I could >> :>specify the dsn as MYSDUMP.GDG(+1) and have each snap dump in a separate >> :>providing I do a close un allocate as a text unit (meaning I would >> :>unallocated the dataset upon closing the snap file). >> >> :>If I read documentation right it seems that upon a close unallocate the >> :>relative gag number gets updated >> >> It would seem to not require any free. Why haven't you tried it? >> >> -- >> Binyamin Dissen >> http://www.dissensoftware.com >> >> Director, Dissen Software, Bar & Grill - Israel >> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocating GDG(+1) using SVC 99
Going to to try it now but it seems logical that the system updates it ( the relative number after the dataset is unallocated ) As from what I remember in multi step job Where the GDG is explicitly allocated the GDG number gets updates only after completion of the entire job Thanks > On Jun 21, 2020, at 5:56 AM, Binyamin Dissen > wrote: > > On Sun, 21 Jun 2020 01:02:41 -0400 Joseph Reichman > wrote: > > :>I am doing a number of snapx type dumps in a started task. I would like to > :>keep each and every one in a separate dsn. It would seem keeping them in a > :>GDG would accomplish this. > > :>The Documentation says that If I turn on S99GDGNT in S99FLAG1 I could > :>specify the dsn as MYSDUMP.GDG(+1) and have each snap dump in a separate > :>providing I do a close un allocate as a text unit (meaning I would > :>unallocated the dataset upon closing the snap file). > > :>If I read documentation right it seems that upon a close unallocate the > :>relative gag number gets updated > > It would seem to not require any free. Why haven't you tried it? > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > > -- > 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: Reading a dump
Since the program is written in C, SYSUDUMP really isn't the easiest place to look for info. CEEDUMP will show the regs and a traceback which is usually all that's needed. See TERMTHDACT option for how to generate a CEEDUMP. Alternatively, use SYSMDUMP and IPCS. There's a learning curve, but for a simple 0C4, it's really not that difficult to get the psw/regs and a traceback. Do: ip verbx ledata 'ceedump' for the traceback and: ip verbx ledata 'cm' for the PSW and regs. Look for last 'CIBH:' block. ABCD: = Abend code (i.e. 0C4) INT: = Interrupt address (address of failing inst) MCH_GPRxx: = registers at abend MCH_PSW: = psw at abend (usually just past the INT: address) In article <590uefpgmu7409rv5v3ufbesol401h8...@4ax.com> you wrote: > Scan the dump looking for RTM2WA > That will have the PSW, the registers and the last branch location. > After looking at those you start debugging. > On Fri, 19 Jun 2020 22:23:49 + Ze'ev Atlas > <004b34e7c98a-dmarc-requ...@listserv.ua.edu> wrote: > :>I admit that I am rusty and did not look at any dump for decades, and when > I did I was coding either Assembler or COBOL and I knew how to decipher the > thing.I am porting a C library libxc to classic z/OS and it compiles cleanly > (most of it, at least).? As is implied by the description, most users of that > thing are running it on Linux or Windows.? Maybe a few on Unix machines. > :>I tried to run its modules on my z/OS machine (genuine IBM, z/OS 2.4),? and > I get S0C4, with nice SYSUDUMP! > :>I have no idea how to begin to look and I am afraid that I compiled it with > wrong options.? Is there any C maven in the audience that could please try to > guide me where to begin looking. > :>I tried to avoid compiling it as dll (that much I sort of knew) but I am > not sure any more.? > :>Ze'ev Atlas > :> > :> > :>-- > :>For IBM-MAIN subscribe / signoff / archive access instructions, > :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- > Binyamin Dissen > http://www.dissensoftware.com > Director, Dissen Software, Bar & Grill - Israel -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocating GDG(+1) using SVC 99
On Sun, 21 Jun 2020 01:02:41 -0400 Joseph Reichman wrote: :>I am doing a number of snapx type dumps in a started task. I would like to :>keep each and every one in a separate dsn. It would seem keeping them in a :>GDG would accomplish this. :>The Documentation says that If I turn on S99GDGNT in S99FLAG1 I could :>specify the dsn as MYSDUMP.GDG(+1) and have each snap dump in a separate :>providing I do a close un allocate as a text unit (meaning I would :>unallocated the dataset upon closing the snap file). :>If I read documentation right it seems that upon a close unallocate the :>relative gag number gets updated It would seem to not require any free. Why haven't you tried it? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reading a dump
Scan the dump looking for RTM2WA That will have the PSW, the registers and the last branch location. After looking at those you start debugging. On Fri, 19 Jun 2020 22:23:49 + Ze'ev Atlas <004b34e7c98a-dmarc-requ...@listserv.ua.edu> wrote: :>I admit that I am rusty and did not look at any dump for decades, and when I did I was coding either Assembler or COBOL and I knew how to decipher the thing.I am porting a C library libxc to classic z/OS and it compiles cleanly (most of it, at least). As is implied by the description, most users of that thing are running it on Linux or Windows. Maybe a few on Unix machines. :>I tried to run its modules on my z/OS machine (genuine IBM, z/OS 2.4), and I get S0C4, with nice SYSUDUMP! :>I have no idea how to begin to look and I am afraid that I compiled it with wrong options. Is there any C maven in the audience that could please try to guide me where to begin looking. :>I tried to avoid compiling it as dll (that much I sort of knew) but I am not sure any more. :>Ze'ev Atlas :> :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
