|
View previous topic :: View next topic
|
| Author |
Message |
Mike.Fulton
New User
Joined: 11 Jun 2014
Posts: 22
Location: Canada
|
|
|
|
I am able to use IGGCSI00 to get a set of datasets back across VSAM, GDG, non-VSAM and I can get fieldname information back such as GDGATTR.
BUT - I have been unable to get information on the space attributes for my datasets.
When I request information for:
NOBYTTRK, NOTRKAU, PRIMSPAC, SCONSPAC, NOEXTNT
I am getting back 'FF'X, which the docs say means:
"n: If the data field to be retrieved has fixed length and does not exist. n is the length of the fixed length data and the data is set to be all 'FF'X."
Why am I not able to retrieve this information? Any ideas? |
|
| Back to top |
|
 |
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| I don't think you can get space info for non-VSAM data sets through CSI. This data is not in the catalog. |
|
| Back to top |
|
|
Mike.Fulton
New User
Joined: 11 Jun 2014
Posts: 22
Location: Canada
|
|
|
|
Ah - ok - thanks - that makes some sense - it would explain why I'm getting the FF's.
Any ideas what service I could use instead to get space information? |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
Space information for non-VSAM data sets is in the VTOC, though not easily digestible.
See the chapter "Using the Volume Table of Contents " in "DFSMSdfp Advanced Services" for your z/OS release. Data set space usage information is in the Format 1 and Format 3 DSCB records for data sets on non extended volumes or data sets located in the track managed space on extended volumes, and in Format 8 and Format 9 DSCBs for data sets allocated in cylinder managed space on extended volumes.
I've done this several times for track managed data sets, though never yet for cylinder managed data sets. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| You could use DCOLLECT to get that information. |
|
| Back to top |
|
|
David Robinson
Active User
Joined: 21 Dec 2011
Posts: 199
Location: UK
|
|
|
|
Can you get the primary space allocation from DCOLLECT for a non-vsam dataset? I know the Data Class segment contains it for SMS datasets, but otherwise the type D records only appear to contain space allocated, space used and secondary space allocation.
I suppose if you know the secondary space allocation, space allocated and number of extents you could work it out. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10888
Location: italy
|
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| David Robinson wrote: |
Can you get the primary space allocation from DCOLLECT for a non-vsam dataset? ...
I suppose if you know the secondary space allocation, space allocated and number of extents you could work it out. |
Actually, no. The primary space itself can be split into up to 5 extents, with no indication where the primary space ends, and extents 2 through 5 are not necessarily allocated in units pf secondary space.
The other problem with your theory is space release; the last extent may not be allocated in units of the secondary space.
Finally, the allocated space can be hashed up in other ways that cannot be readily predicted.
For example -
| Code: |
---NO--RELTRK--START CCHH--END CCHH--TRACKS
1 00000 0C8E0000 0C92000E 75
2 0004B 00510000 0055000E 75 |
I think (but who knows for sure) the first extent is primary and the second extent is secondary. How about this data set -
| Code: |
---NO--RELTRK--START CCHH--END CCHH--TRACKS
1 00000 01820000 0185000E 60
2 0003C 00860000 0086000E 15
3 0004B 01AC0000 01AD000E 30 |
The first two extents may be primary, and the third secondary, but who knows?
I've been thinking about this for more than 30 years and never came up with any reliable ideas. |
|
| Back to top |
|
|
David Robinson
Active User
Joined: 21 Dec 2011
Posts: 199
Location: UK
|
|
|
|
Good point Steve, of course, nothing is ever that straightforward!
I think also that the reverse can occur, that it to say if a dataset grows to a second extend because the primary space allocation was insufficient, but that secondary extent happens to be on a contiguous portion of disk to the first extent, then it will subsequently be reported as one extent, not two. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| David Robinson wrote: |
| ... I think also that the reverse can occur, that it to say if a dataset grows to a second extend because the primary space allocation was insufficient, but that secondary extent happens to be on a contiguous portion of disk to the first extent, then it will subsequently be reported as one extent, not two. |
I'm pretty sure DADSM is not that smart, it will be 2 extents, even if they are contiguous. However, DADSM does combine free space extents. DADSM (Direct Access Disk? Space Management).
The issues are multiple instances of open data sets and multiple systems sharing the volume. |
|
| Back to top |
|
|
Mike.Fulton
New User
Joined: 11 Jun 2014
Posts: 22
Location: Canada
|
|
|
|
Thanks for the info folks.
What I'm trying to do is determine the attributes of the dataset so that I can do the equivalent of an 'allocate like' on another z/OS box.
So - I'm hoping to get (programmatically) the equivalent of the 3.2 information for an allocated dataset (primary/secondary/allocation), and it'd be handy if I could calculate (roughly) total space used so far.
Looking at the VTOC, it appears I can get most of that 'not easily digestible' information (that was a good way to put it ;) . Do people agree that'd be the best place for me to extract this information? |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| Mike.Fulton wrote: |
| ... Looking at the VTOC, it appears I can get most of that 'not easily digestible' information (that was a good way to put it ;) . Do people agree that'd be the best place for me to extract this information? |
It's about the only place. While it hasn't been tested in this form, this code will give you an idea about how to get allocated space for track managed data sets.
| Code: |
USING *,12
USING F1DSCB,10
SR 9,9 LOAD NUMBER OF EXTENTS
IC 9,DS1NOEPV IN THE DATA SET
LA 0,3 LOAD NUMBER OF EXTENT ENTRIES IN
* FORMAT 1 DSCB
LA 1,DS1EXT1 LOAD ADDR OF FIRST EXTENT ENTRY
SR 2,2 INIT NUMBER OF TRACKS IN DATA SET
BAL 14,XSPACE GET TRACKS DEFINED IN F1 DSCB
LTR 9,9 TEST REMAINING EXTENTS
BZ DONE BR IF ALL EXTENTS PROCESSED
* READ THE NEXT DSCB USING DS1PTRDS, COPY ITS ADDRESS TO REG 10
USING F3DSCB,10
NEXTDSCB CLI DS3FMTID,C'2' TEST IF FORMAT 2 DSCB
BNE TESTF3 BR IF NOT
* READ THE NEXT DSCB USING DS3PTRDS, COPY ITS ADDRESS TO REG 10
B NEXTDSCB
TESTF3 CLI DS3FMTID,C'3' TEST IF FORMAT 3 DSCB
BE TESTKEY BR IF SO
DC H'0' OOPS
TESTKEY CLC DS3KEYID,=4X'03' TEST DS3KEYID
BE SCANKEY BR IF OK
DC H'0' OOPS
SCANKEY LA 0,4 LOAD NUMBER OF EXTENT ENTRIES IN KEY
LA 1,DS3EXTNT LOAD ADDR OF FIRST EXTENT ENTRY
BAL 14,XSPACE PROCESS THE EXTENTS
LTR 9,9 TEST REMAINING EXTENTS IN DATA SET
BZ DONE BR IF NONE LEFT
LA 0,9 LOAD NUMBER OF EXTENT ENTRIES IN
* DATA AREA
LA 1,DS3ADEXT LOAD ADDR OF NEXT EXTENT
BAL 14,XSPACE PROCESS EXTENTS IN DATA AREA
LTR 9,9 TEST IF MORE EXTENTS
BZ DONE BR IF ALL DONE
* READ THE NEXT DSCB USING DS3PTRDS, COPY ITS ADDRESS TO REG 10
B NEXTDSCB
DROP 10
DONE ...
* REGISTERS --
* 0 -- NUMBER OF EXTENTS IN GROUP
* 1 -- ADDRESS OF FIRST EXTENT IN GROUP
* 2 -- RUNNING COUNT OF TRACKS IN DATA SET
* 9 -- REMAINING EXTENTS IN DATA SET
* REGISTERS 15, 0, 1, 2, 9 ARE ALTERED, ALL OTHER REGISTERS UNCHANGED
XSPACE SAVE 14 SAVE REG 14
XNEXT LH 14,2(,1) LOAD ADDR OF 1ST CYLINDER
N 14,=A(X'FFFF') ISOLATE ADDRESS
MH 14,TRKSCYL MULTIPLY BY TRKS / CYLINDER
AH 14,4(,1) ADD STARTING TRACK
LH 15,6(,1) LOAD ADDR OF LAST CYLINDER
N 14,=A(X'FFFF') ISOLATE ADDRESS
MH 15,TRKSCYL MULTIPLY BY TRACKS / CYLINDER
AH 15,8(,1) ADD ENDING TRACK
SR 15,14 COMPUTE EXTENT SIZE
BNM *+L'*2 BR IF OK
DC H'0' OOPS
* THIS LOAD ADDRESS IS USING THE INSTRUCTION AS A 3 INPUT ADDER
LA 2,1(15,2) ADD TRACKS IN EXTENT TO TOTAL
LA 1,(DS1EXT2-F1DSCB)-(DS1EXT1-F1DSCB) COMPUTE ADDR OF
* NEXT EXTENT ENTRY
BCT 9,*+L'*+4 BR IF MORE EXTENTS IN DATA SET
B XDONE ALL EXTENTS IN DATA SET HAVE BEEN
* PROCESSED
BCT 0,XNEXT GO PROCESS NEXT EXTENT IN GROUP
XDONE RETURN 14 RESTORE REG 14 & RETURN
...
TRKSCYL DS H
F1DSCB DSECT
IECSDSL1 1
F3DSCB DSECT
IECSDSL1 3 |
|
|
| Back to top |
|
|
Mike.Fulton
New User
Joined: 11 Jun 2014
Posts: 22
Location: Canada
|
|
|
|
| Thanks Steve! |
|
| Back to top |
|
|
Mike.Fulton
New User
Joined: 11 Jun 2014
Posts: 22
Location: Canada
|
|
|
|
| Alright Steve - after having read the code, I think I get it. However, I am not sure how you have calculated the TRKSCYL - I imagine it's before this point. Is that something that's available in the VTOC, or do I need to calculate it based on lrecl/blksize/type of dasd etc? |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
Good question. There are two or maybe 3 ways.- I think it's still in the Format 4 DSCB for the volume.
- If the volume has a DD statement, look in the output generated with DEVTYPE with the DEVTAB option. The output is described by the IHADVA macro in SYS1.MACLIB.
- If you have a UCB, use the device characteristics area. You access it following the instructions in SYS1.MODGEN(IHADVCT). This is what I usually use.
Of course, if you're lazy, just use 15. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
Oops.
Two issues, both in XSPACE.
LH 15,6(,1)
N 14,=A(X'FFFF')
should be
LH 15,6(,1)
N 15,=A(X'FFFF')
and
LA 1,(DS1EXT2-F1DSCB)-(DS1EXT1-F1DSCB)
should be
AHI 1,(DS1EXT2-F1DSCB)-(DS1EXT1-F1DSCB)
or
LA 1,(DS1EXT2-F1DSCB)-(DS1EXT1-F1DSCB)(,1) |
|
| Back to top |
|
|
Mike.Fulton
New User
Joined: 11 Jun 2014
Posts: 22
Location: Canada
|
|
|
|
Alright - I am able to calculate the number of tracks from the first 3 extents correctly.
I am not sure how to calculate where the DSCB Format 2 or 3 control block is given the CCHHR 5 byte entity at the end of the DSCB Format 1.
google has not been my friend, nor the books. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| How are you getting the Format 1 DSCB? |
|
| Back to top |
|
|
Mike.Fulton
New User
Joined: 11 Jun 2014
Posts: 22
Location: Canada
|
|
|
|
Apologies if this shows up twice... I submitted it and it hasn't shown up...
I think your question may have helped me answer my problem, but I'm not sure yet.
I am calling SVC 27 (OBTAIN) to get the DSCB. I am passing in a 'dscbs' parameter of 1 - so I am only providing room for 1 DSCB. I think I need to bump that up to provide room for the other DSCBs. |
|
| Back to top |
|
|
Mike.Fulton
New User
Joined: 11 Jun 2014
Posts: 22
Location: Canada
|
|
|
|
Ok - I called SVC 27 / OBTAIN requesting 3 DSCB's instead of just room for 1. That gives me my Format 3 DSCBs.
BUT - one thing I am not sure about is how to accurately determine -where- those Format 3 DSCBs will be in memory.
From inspection, I see that the first Format 3 DSCB is 44 bytes -after- the end of the Format 1 DSCB. The OBTAIN documentation I was able to find just indicated it would be after - anyone know how I am supposed to get addressability to the Format 3 DSCB if I request it be returned from OBTAIN? |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| Code: |
MVC CCHHR,DSxPTRDS
OBTAIN CAMLST
...
CAMLST CAMLST SEEK,CCHHR,VOL,DSCBAREA
VOL DC CL6'XXXXXX'
DC 0D'0'
DSCBAREA DC XL140'0' |
OBTAIN with CAMLST SEEK is described in DFSMSdfp Advanced Services in the same area as OBTAIN with CAMLST SEARCH. I've never used the multiple DSCB feature of OBTAIN, though I know about it. After reading about your problems with it, I'm reluctant to try! |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| David Robinson wrote: |
Good point Steve, of course, nothing is ever that straightforward!
I think also that the reverse can occur, that it to say if a dataset grows to a second extend because the primary space allocation was insufficient, but that secondary extent happens to be on a contiguous portion of disk to the first extent, then it will subsequently be reported as one extent, not two. |
Well, no, check this -
| Code: |
---NO--RELTRK--START CCHH--END CCHH--TRACKS
1 00000 0012000D 0012000D 1
2 00001 001E000E 001E000E 1
3 00002 001F000E 001F000E 1
4 00003 00220000 00220000 1
5 00004 00220008 00220008 1
6 00005 002F000E 002F000E 1
7 00006 00590002 00590002 1
8 00007 0082000E 0082000E 1
9 00008 0088000E 0088000E 1
10 00009 0109000B 0109000B 1
11 0000A 0109000C 0109000C 1
12 0000B 0109000D 0109000D 1
13 0000C 0109000E 0109000E 1
14 0000D 010F0000 010F0000 1
15 0000E 010F0001 010F0001 1
16 0000F 010F0002 010F0002 1 |
The data set was created by copying SMF data to it, with the intent it would get a B37. |
|
| Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009
Posts: 592
Location: London
|
|
|
|
| David Robinson wrote: |
Good point Steve, of course, nothing is ever that straightforward!
I think also that the reverse can occur, that it to say if a dataset grows to a second extend because the primary space allocation was insufficient, but that secondary extent happens to be on a contiguous portion of disk to the first extent, then it will subsequently be reported as one extent, not two. |
You're right...for SMS managed VSAM datasets 'Extent Consolidation' takes effect so that extents are merged into one if a subsequent extent can be taken next to the previous one. There's some restrictions for RLS datasets, catalogs and VVDS's, page space etc.
pic.dhe.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.idad400%2Fspalloc.htm
You also have Dataclas Space Constraint Relief these days that will alter extent sizes to fit available space.
Curious why you're trying to write a utility for this when there are so many already out there. Naviquest (ISMF batch), FDREPORT and DMS to name a few. Even the REXX LISTDSI and SYSDSN functions might help. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| Pete Wilson wrote: |
| ... Curious why you're trying to write a utility for this when there are so many already out there. Naviquest (ISMF batch), FDREPORT and DMS to name a few. Even the REXX LISTDSI and SYSDSN functions might help. |
Pete - It's worth learning how to do this. Maybe -- unlikely -- he'll figure out a better way, either in terms of doing the mechanics better or in terms of displaying the information. |
|
| Back to top |
|
|
|
|
