Automatic SVCDUMP Dataset space allocation -Query
Gaur
with saying that they don't have complete dump and Batch requested to
make the changes in the automatic dump capturing process I had to go
back again for process and could not figure out where and how the
space is getting allocated for these datasets...
Here's my observation while doing investigation :-
1. Status of our dump dataset
IEE852I 02.13.47 SYS1.DUMP STATUS
026
SYS1.DUMP DATA SETS AVAILABLE=002 AND
FULL=000
CAPTURED DUMPS=0000, SPACE USED=00000000M, SPACE
FREE=00005000M
AUTOMATIC ALLOCATION IS:
ACTIVE
AVAILABLE SMS CLASSES:
(DATA=DCEXTSP,MGMT=,STOR=)
NO DASD VOLUMES
DEFINED
NAME=SYS7A.DUMP.S&SYSNAME..D&LDATE..T<IME..N&SEQ
EXAMPLE=SYS7A.DUMP.S1X01.D100714.T021347.N00000
SYS1.DUMP AVAILABLE DASD DATA SETS :
10-11
Shows the dataclass=DCEXTSP which I thought responsible for allocating
Primary and secondary space ..However that's not true since these are
not defined in our environment.
DATA CLASS
LIST
Entries 1-1 of
1
Data Columns
6-11 of 47
CDS Name :
ACTIVE
Enter Line Operators
below:
LINE DATACLAS AVG SPACE
SPACE
OPERATOR NAME KEYLEN KEYOFF AVGREC VALUE PRIMARY
SECONDARY
---(1)---- --(2)--- -(6)-- -(7)-- -(8)-- -(9)- -(10)-- --
(11)---
DCEXTDMP --- ----- - ----- ------
------
---------- -------- ------ BOTTOM OF DATA ------ --------
----------
2. Now I tried with the test console dump for one test job and below
is output and screen shot..
IEF196I IGD17070I DATA SET
SYS7A.DUMP.S1X01.D100714.T004238.N00004
IEF196I ALLOCATED SUCCESSFULLY WITH 4
STRIPE(S).
IEF196I IGD101I SMS ALLOCATED TO DDNAME
(SYS00007)
IEF196I DSN
(SYS7A.DUMP.S1X01.D100714.T004238.N00004 )
IEF196I STORCLAS (PRD10202) MGMTCLAS (PRD) DATACLAS
(DCEXTDMP)
IEF196I VOL SER NOS=
1X0DM0,1X0DM1,1X0DM2,1X0DM3
IEF196I IGD104I SYS7A.DUMP.S1X01.D100714.T004238.N00004
RETAINED,
IEF196I
DDNAME=SYS00007
IEA611I COMPLETE DUMP ON SYS7A.DUMP.S1X01.D100714.T004238.N00004
250
DUMPID=004 REQUESTED BY JOB (*MASTER*)
NONVSAM -------
SYS7A.DUMP.S1X01.D100714.T013548.N00005
IN-CAT ---
SYS8C.UCAT1X.SYS02
HISTORY
DATASET-OWNER-----(NULL)
CREATION--------2010.195
RELEASE----------------2
EXPIRATION------0000.000
ACCOUNT-INFO-----------------------------------
(NULL)
SMSDATA
STORAGECLASS ---PRD10202 MANAGEMENTCLASS------
PRD
DATACLASS ------DCEXTDMP LBACKUP
---0000.000.0000
VOLUMES
VOLSER------------1X0DM2 DEVTYPE------X'3010200F'
FSEQN----------
VOLSER------------1X0DM3 DEVTYPE------X'3010200F'
FSEQN----------
VOLSER------------1X0DM0 DEVTYPE------X'3010200F'
FSEQN----------
VOLSER------------1X0DM1 DEVTYPE------X'3010200F'
FSEQN----------
ASSOCIATIONS--------
(NULL)
ATTRIBUTES
STRIPE-COUNT-----------4
Data Set Name . . . . :
SYS7A.DUMP.S1X01.D100714.T015331.N00006
General Data Current
Allocation
Management class . . : PRD Allocated blocks . :
12,796
Storage class . . . : PRD10202 Allocated extents . :
4
Volume serial . . . : 1X0DM2
+
Device type . . . . :
3390
Data class . . . . . : DCEXTDMP Current
Utilization
Organization . . . : PS Used blocks . . . . :
12,796
Record format . . . : FBS Used extents . . . :
4
Record length . . . :
4160
Block size . . . . :
24960
1st extent blocks . :
3200
Secondary blocks . :
7756
Data set name type : EXTENDED SMS Compressible :
NO
Creation date . . . : 2010/07/14 Referenced date . . :
2010/07/14
Expiration date . . :
***None***
No where I could find any answer how the space is defined for the
SYS7A.DUMP.** datasets.. I presumed since dataclass=dcextdmp point to
storage group SGDUMP which is having 4 volume defined ..my SVCDUMP
dataset would try to extend to all these 4 volumes and acquire all
space ..However these all are 3390-3 model and I see our process of
clearing the dump dataset is also pretty fast to avoid situation where
volumes are filled as soon as other svcdump request kicked on..
Can someone point me out to the manual/redbook which talk about
process of space allocation here...
Also fyi ..i have seen for the message which says PARTIAL complete
could not see that either..
Ravi Gaur
NAME=SYS7A.DUMP.S&SYSNAME..D&LDATE..T<IME..N&SEQ
Enter Line Operators
below:
ATTRIBUTES
STRIPE-COUNT-----------4
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Barbara Nitz
dynamically by DUMPSRV address space. The customer doesn't have influence
over it (other than telling the system which dataclass to use which in turn will
lead to right volumes that hopefully have enough free space).
Whenever you see a *partial* dump, there is a reason code *why* that dump
was partial. And there are tons of reasons why a dump might be partial other
than dump data set too small. So first of all, get a copy of that dump and use
IPCS to see the reason codes (yes, they're in there.) Or take a look at the
syslog when the dump was taken and check the iea611i message.
I would not put it past *any* vendor (including IBM) to NOT having properly
analyzed the reason codes themselves and hence coming back with total
bullshit.
The most common reason for a partial dump these days is the very old, very
inappropriate MAXSPACE default which is still 500M. This governs the size of
the dump dataspace, and if that is filled before the dump is fully captured,
then you'll get a partial dump. If OMVS is involved, 500M if definitely not large
enough, depending on what you need to dump. So if you haven't changed that
default to something else, this might be your problem.
Which is speculation without the actual code for the partial dump.
Regards, Barbara Nitz
ps: My "favourite" bullshit is having a vendor tell me that 'storage is not in
dump' because they are too stupid to realize that the address is in another
address space. (And then request another, "complete" dump.) So they look
very incompetent when *I* can see the storage but they cannot. I am always
willing to shameface incompetence, though.
The next one is 'storage not in dump' when we have a standalone dump and I
can prove that the actual address isn't getmained, so *cannot* be in dump. I
hate having to play these games!
Rob Scott
> I am always willing to shameface incompetence, though.
I always like your posts but the above made my day - well said.
Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com
Shane Ginnane
to keep my head down in case I got on the other end of a phone call with
Barbara ...
Lots of fun ... ;-)
Shane ...
On Wed, Jul 14th, 2010 at 6:27 PM, Rob Scott wrote:
> Barbara,
>
> > I am always willing to shameface incompetence, though.
>
> I always like your posts but the above made my day - well said.
----------------------------------------------------------------------
Barbara Nitz
I am also willing to make a few exceptions if I deal with someone from this list
or if I can see that someone honestly tries but that no one ever educated
them properly in the first place.
But having had a few altercations with *some* vendors' support, they don't
gainsay me much anymore. Also a mixed blessing, because I might be wrong,
after all!
Regards, Barbara
Shane Ginnane
.... :p
Shane ...
On Wed, Jul 14th, 2010 at 7:20 PM, Barbara Nitz wrote:
> Before this goes any more off-topic :-)
----------------------------------------------------------------------
Elardus Engelbrecht
>I would not put it past *any* vendor (including IBM) to NOT having properly
analyzed the reason codes themselves and hence coming back with total
bullshit.
>ps: My "favourite" bullshit is having a vendor tell me that 'storage is not in
dump' because ....
>I am always willing to shameface incompetence, though.
>I hate having to play these games!
My oh my, Barbara, seemed we all need to review our testaments, if you're
around here... Careful IBM-MAIN... You'll need gloves to work with her... ;-D
Nicely said, Barbara! I wish there are more 'vendor' bashers like you! ;)
Groete / Greetings
Elardus Engelbrecht
PS: If I said anything BS, please excuse me... 8-)
J R
> Date: Wed, 14 Jul 2010 04:20:54 -0500
> From: nitz...@GMX.NET
> Subject: Re: Automatic SVCDUMP Dataset space allocation -Query
> To: IBM-...@bama.ua.edu
Rick Fochtman
>Now I know Rob is good, but If I worked for a vendor I'd reckon I'd want
>to keep my head down in case I got on the other end of a phone call with
>Barbara ...
>
>Lots of fun ... ;-)
>
>Shane ...
>
>On Wed, Jul 14th, 2010 at 6:27 PM, Rob Scott wrote:
>
>
>
>>Barbara,
>>
>>
>>
>>>I am always willing to shameface incompetence, though.
>>>
>>>
>>I always like your posts but the above made my day - well said.
>>
>>
---------------------------------<unsnip>--------------------------------------
But let us always remember that a select few displays of incompetence
can be VERY amusing. :-)
Rick
Rick Fochtman
>Before this goes any more off-topic :-)
>
>I am also willing to make a few exceptions if I deal with someone from this list
>or if I can see that someone honestly tries but that no one ever educated
>them properly in the first place.
>
>But having had a few altercations with *some* vendors' support, they don't
>gainsay me much anymore. Also a mixed blessing, because I might be wrong,
>after all!
>
>Regards, Barbara
>
>
---------------------------------<unsnip>---------------------------------
Barbara, I think we've all been in that situation at least once in our
careers. Back in the days of telephone support from IBM, I was quite
ready to cast about half of the level one support staff into the
infernal regions, along with their parents, whose morals I questioned.
When I called I was asked some pretty stupid questions because level 1
suppport people weren't the most 'computer literate'. Especially one who
asked me what level of OS/2 I was running on my 3090-300J!! When I asked
to speak to his supervisor he hung up on me. Shortly after that, IBMLINK
came into the picture and I, for one, never looked back.
Rick