DBB LECL will almost certainly not assemble (as John G. was pointing out, a
bit obtusely). Should be LRECL.
A DSECT is just a name for the variables presumably (the assembler trusts
you) pointed to by some register. (There are additional forms of USING but
let's not go there now.) If I say USING MYDSECT,R5 and dump MYDSECT, John
says USING HISDSECT,R5 and dumps HISDSECT, and you just dump whatever R5
points to, we are all going to get the same output. It does not matter
whether my DSECT is a bunch of halfwords, John's is a bunch of doublewords,
and the storage in question is actually a bunch of bit fields.
Dropping back from the dump question to DSECTs in general, if I say
MYDSECT DSECT
FOO DS F'0'
BAR DS F'0'
...
USING MYDSECT,R5
L R1,BAR
the only thing I have accomplished is a (theoretically) more readable
version of
L R1,4(,R5)
A DSECT is not really there -- it is just a story you have told the
assembler about what you claim is there. If R5 is pointing out in the weeds
then L R1,BAR is going to blow up exactly the same as L R1,4(,R5). Neither
the assembler nor any sort of runtime validates USING MYDSECT,R5 (beyond the
syntax). The L R1,BAR above will always assemble cleanly, even if the
preceding instruction is L R5,=F'-1', which is obviously going to produce a
S0C4 then at runtime.
Perhaps you already knew that. Perhaps the S0C4 is unrelated to DSECTs.
I have not used SNAP in about fifty years (literally). I don't think
PDATA=ALL should be dependent on DSECTs or anything else -- it should just
dump all of your program storage. No amount of erroneous DSECT definitions
should matter one iota. Or are you also using SNAP LIST= ? I am not certain
if LIST=(MYDSECT+X'80000000',MYDSECT+100) would assemble but it will not
work at run time -- an address constant in memory will NEVER assemble
pointing to a DSECT because a DSECT is just a story you have told the
assembler about a register, not storage that exists at assembly time -- and
might well S0C4, I don't know.
Do you really need TCB? If the SNAP is for your basic program storage then
TCB is just adding to the confusion. How do you set R5? Is the DCB in 24-bit
storage?
On what instruction is the S0C4? Your hand-coded assembler? Inside a macro
expansion? Out in SNAP magic land?
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Scott Ford
Sent: Friday, May 25, 2012 12:33 PM
To: IBM-MAIN@bama.ua.edu
Subject: Snap dump question
All:
I have a program that uses a dsect...filling in fields and then calls an
external program.
I am doing a RACF extract through IRRSEQ00..
OPEN (SNAPOUT,OUTPUT)
LA R3,SNAPOUT
SNAP DCB=(3),TCB=(5),PDATA=ALL
CLOSE SNAPOUT
L R15,=V(IRRSEQ00)
BALR R14,R15
** dcb **
SNAPOUT DCB DDNAME=SNAPOT,DSORG=PS,MACRF=(W),RECFM=VBA,LECL=125
I want to see the the contents of the dsect prior to the call, I am
experiencing the dreaded S0C4-11 When I execute the above code the SNAPOUT
contents shows nada..
can anyone shed some light on my mistake, yes I am admiting I make mistakes
:(
Regards,
Scott J Ford
Software Engineer
http://www.identityforge.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
