Re: Snap dump question

[Charles Mills]

Aw John, don't be grumpy. By obtuse I just meant you merely alluded to the
solution, you didn't explicitly say "if you really coded LECL you need to
correct it to LRECL." No harm intended. Sorry for the offense.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of John Gilmore
Sent: Friday, May 25, 2012 5:47 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Snap dump question

Charles Mills writes


DBB LECL will almost certainly not assemble (as John G. was pointing
out, a bit obtusely). Should be LRECL


Equally, 'DBB' should of course be 'DCB'.

My point--serendipitously well illustrated by what you typed--was
that, since the OP obviously knows that 'LECL'. should be 'LRECL',
there was a strong possibility that his typo was a transcription
error, defective in his post but not in his code.  In reviewing the
language I used to make this point I find no basis for the notion that
it is obtuse

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Snap dump question

[Binyamin Dissen]

On Sat, 26 May 2012 13:02:03 -0400 Scott Ford  wrote:

:>I built the plist for a call to irrseq00 , I will post my code a bit later. 
Thanks for the reply

You didn't seem to set up R1 to point to 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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Snap dump question

[Scott Ford]

Peter,

I built the plist for a call to irrseq00 , I will post my code a bit later. 
Thanks for the reply

Scott ford
www.identityforge.com

On May 26, 2012, at 12:31 PM, Peter Relson  wrote:

>> I am experiencing the dreaded S0C4-11
> 
> I didn't see an answer to the question of just where the S0C4-11 occurred.
> 
> I somewhat doubt that SNAP would end with an S0C4-11 if your data was 
> incorrect. It would catch the program interrupt, and either retry to give 
> you back a return code or change the completion code.
> That leads me to suspect that you never made it to the SVC 33 that is part 
> of SNAP.
> 
> Look in your program for whatever bug is indicated by the error location.
> 
> Peter Relson
> z/OS Core Technology Design
> 
> --
> 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

Re: Snap dump question

[Peter Relson]

>I am experiencing the dreaded S0C4-11

I didn't see an answer to the question of just where the S0C4-11 occurred.

I somewhat doubt that SNAP would end with an S0C4-11 if your data was 
incorrect. It would catch the program interrupt, and either retry to give 
you back a return code or change the completion code.
That leads me to suspect that you never made it to the SVC 33 that is part 
of SNAP.

Look in your program for whatever bug is indicated by the error location.

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Snap dump question

[Scott Ford]

John,

Your so far from impolite. I appreciate intelligence and frankness. I will post 
my code a snippet a bit later..I know I made mistakes , so I need a another 
pair of eyes I don't have within the company I work..the black arts of 
assembler are only practiced by a few ...good men and women...thanks for the 
option...

Scott ford
www.identityforge.com

On May 25, 2012, at 8:47 PM, John Gilmore  wrote:

> Charles Mills writes
> 
> 
> DBB LECL will almost certainly not assemble (as John G. was pointing
> out, a bit obtusely). Should be LRECL
> 
> 
> Equally, 'DBB' should of course be 'DCB'.
> 
> My point--serendipitously well illustrated by what you typed--was
> that, since the OP obviously knows that 'LECL'. should be 'LRECL',
> there was a strong possibility that his typo was a transcription
> error, defective in his post but not in his code.  In reviewing the
> language I used to make this point I find no basis for the notion that
> it is obtuse.  (It is at once clear and polite, but perhaps I should
> add that I am capable of being impolite.)
> 
> While I am responding, I do not much like your
> 'definition'/characterization of a DSECT.  A DSECT is a portable
> putative storage template.  It describes but neither allocates nor
> initializes a block of storage.
> 
> Like other preogramming constructs, a DSECT can be misused.  You are
> of course correct that if pointed "in the weeds" it will yield
> gibberish and, with luck, a quick ABEND.
> 
> John Gilmore, Ashland, MA 01721 - USA
> 
> --
> 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

Re: Snap dump question

[John Gilmore]

Charles Mills writes


DBB LECL will almost certainly not assemble (as John G. was pointing
out, a bit obtusely). Should be LRECL


Equally, 'DBB' should of course be 'DCB'.

My point--serendipitously well illustrated by what you typed--was
that, since the OP obviously knows that 'LECL'. should be 'LRECL',
there was a strong possibility that his typo was a transcription
error, defective in his post but not in his code.  In reviewing the
language I used to make this point I find no basis for the notion that
it is obtuse.  (It is at once clear and polite, but perhaps I should
add that I am capable of being impolite.)

While I am responding, I do not much like your
'definition'/characterization of a DSECT.  A DSECT is a portable
putative storage template.  It describes but neither allocates nor
initializes a block of storage.

Like other preogramming constructs, a DSECT can be misused.  You are
of course correct that if pointed "in the weeds" it will yield
gibberish and, with luck, a quick ABEND.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Snap dump question

[Shmuel Metz (Seymour J.)]

In <1337974360.45500.yahoomail...@web164501.mail.gq1.yahoo.com>, on
05/25/2012
   at 12:32 PM, Scott Ford  said:

>I have a program that uses a dsect

To describe what? Please show the code that acquires the storage and
establishes addressability.

> L R15,=V(IRRSEQ00)
> BALR  R14,R15

R1?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Snap dump question

[Charles Mills]

> DBB LECL will almost certainly not assemble (as John G. was pointing out,
a bit obtusely). Should be LRECL.

I meant DCB LECL and LRECL, obviously.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Charles Mills
Sent: Friday, May 25, 2012 3:28 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Snap dump question

DBB LECL will almost certainly not assemble (as John G. was pointing out, a
bit obtusely). Should be LRECL.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Snap dump question

[Charles Mills]

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  DSF'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'8000',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

Re: Snap dump question

[Scott Ford]

John:
 
That was correct in my code, thats what the manual gave..but I also found some 
of their parameter examples wrong

Scott J Ford
Software Engineer
http://www.identityforge.com
 
 


 From: John Gilmore 
To: IBM-MAIN@bama.ua.edu 
Sent: Friday, May 25, 2012 4:19 PM
Subject: Re: Snap dump question
  
On 5/25/12, John Gilmore  wrote:
> Scott,
>
> Is
>
> LECL=125
>
> just a typo for LRECL=125 in your post, or is it LECL in your code too?
>
> John Gilmore, Ashland, MA 01721 - USA
>


-- 
John Gilmore, Ashland, MA 01721 - USA

--
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

Re: Snap dump question

[John Gilmore]

On 5/25/12, John Gilmore  wrote:
> Scott,
>
> Is
>
> LECL=125
>
> just a typo for LRECL=125 in your post, or is it LECL in your code too?
>
> John Gilmore, Ashland, MA 01721 - USA
>


-- 
John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Snap dump question

[John Gilmore]

Scott,

Is

LECL=125

just a typo for LRECL=125 in your post, or is it LECL in your code too?

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Snap dump question

[Scott Ford]

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