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
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
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 J
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 TA
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 genera
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 dealloc
+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
sta
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 dif
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
> 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 grani
[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 tra
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-M
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:
13 matches
Mail list logo
