Re: Primary allocation of a dataset

2015-05-15 Thread Shmuel Metz (Seymour J.)
In
<874b151289704e46a874bf2ae6fdd8d1210a5...@kl126r4b.cs.ad.klmcorp.net>,
on 05/13/2015
   at 01:55 PM, "Vernooij, CP (ITOPT1) - KLM" 
said:

>I don't know if it is, but I would be surprised if it is, because 
>is useless information for the system.

How is that relevant. The ystrem keeps ttrack of as lot of data that
ar useful for the user but not for the system.

>Furthermore, you know who created the data set and when, so you 
>can find the JCL, Rexx of Dynalloc parameterlist that created the 
>data set.

Maybe in the world to come; certainly not in this world.
 
-- 
 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...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Primary allocation of a dataset

2015-05-14 Thread Vernooij, CP (ITOPT1) - KLM
The key of the discussion was that after the dataset has been allocated, you 
can retrieve the info of the primary extent of that moment, but not the primary 
space that was requested at allocation time, which is not the same because of 
several reasons (primary space in up to 5 extents, adjacent extent merging, 
RLSE processing, DSS extent consolidation etc.)

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Coalbran
Sent: Thursday, May 14, 2015 9:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Primary allocation of a dataset

I missed most of the thread but, is this what you mean, in REXX you can
issue:

RC = LISTDSI('K248610.USER.EXEC' "RECALL DIRECTORY SMSINFO")

Which might give results something like this...
 
SYSDSNAME= K248610.USER.EXEC 
SYSVOLUME= PRI001 
SYSUNIT  = 3390 
SYSDSORG = PO 
SYSRECFM = FB 
SYSLRECL = 80 
SYSBLKSIZE   = 23200 
SYSKEYLEN= 0 
SYSALLOC = 290 
SYSUSED  = N/A 
SYSUSEDPAGES = 1626 
SYSPRIMARY   = 290 
SYSSECONDS   = 90 
SYSUNITS = BLOCK 
SYSEXTENTS   = 1 
SYSCREATE= 2012/102 
SYSREFDATE   = 2015/134 
SYSEXDATE= 0 
SYSPASSWORD  = NONE 
SYSRACFA = GENERIC 
SYSUPDATED   = NO 
SYSTRKSCYL   = 15 
SYSBLKSTRK   = N/A 
SYSADIRBLK   = NO_LIM 
SYSUDIRBLK   = N/A 
SYSMEMBERS   = 391 
SYSREASON=  
SYSMSGLVL1   = 
SYSMSGLVL2   = 
SYSDSSMS = DATA_LIBRARY 
SYSDATACLASS = NODCB 
SYSSTORCLASS = TSO 
SYSMGMTCLASS = STANDARD 
 
/Steve




From:   "Shmuel Metz (Seymour J.)" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   2015-05-13 19:10
Subject:        Re: Primary allocation of a dataset
Sent by:IBM Mainframe Discussion List 



In , on 05/06/2015
   at 01:43 PM, Fred van der Windt 
said:

>I want to retrieve the primary allocation of a dataset.

You can't get that from the DSCB; the NVR has it for SMS datasets.
There is no indication in the VTOC as to which extent came from the primary. 
The best that you can do is to look at the first extent and hope that it is the 
only extent initially allocated. Even then you can't tell the allocation units.

Query: does that change on an EAV?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
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...@listserv.ua.edu with the message: INFO IBM-MAIN




Såvida annat inte anges ovan: / Unless stated otherwise above:
IBM Svenska AB
Organisationsnummer: 556026-6883
Adress: 164 92 Stockholm

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Primary allocation of a dataset

2015-05-14 Thread Steve Coalbran
I missed most of the thread but, is this what you mean, in REXX you can 
issue:

RC = LISTDSI('K248610.USER.EXEC' "RECALL DIRECTORY SMSINFO")

Which might give results something like this...
 
SYSDSNAME= K248610.USER.EXEC 
SYSVOLUME= PRI001 
SYSUNIT  = 3390 
SYSDSORG = PO 
SYSRECFM = FB 
SYSLRECL = 80 
SYSBLKSIZE   = 23200 
SYSKEYLEN= 0 
SYSALLOC = 290 
SYSUSED  = N/A 
SYSUSEDPAGES = 1626 
SYSPRIMARY   = 290 
SYSSECONDS   = 90 
SYSUNITS = BLOCK 
SYSEXTENTS   = 1 
SYSCREATE= 2012/102 
SYSREFDATE   = 2015/134 
SYSEXDATE= 0 
SYSPASSWORD  = NONE 
SYSRACFA = GENERIC 
SYSUPDATED   = NO 
SYSTRKSCYL   = 15 
SYSBLKSTRK   = N/A 
SYSADIRBLK   = NO_LIM 
SYSUDIRBLK   = N/A 
SYSMEMBERS   = 391 
SYSREASON=  
SYSMSGLVL1   = 
SYSMSGLVL2   = 
SYSDSSMS = DATA_LIBRARY 
SYSDATACLASS = NODCB 
SYSSTORCLASS = TSO 
SYSMGMTCLASS = STANDARD 
 
/Steve




From:   "Shmuel Metz (Seymour J.)" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   2015-05-13 19:10
Subject:        Re: Primary allocation of a dataset
Sent by:IBM Mainframe Discussion List 



In , on 05/06/2015
   at 01:43 PM, Fred van der Windt 
said:

>I want to retrieve the primary allocation of a dataset.

You can't get that from the DSCB; the NVR has it for SMS datasets.
There is no indication in the VTOC as to which extent came from the
primary. The best that you can do is to look at the first extent and
hope that it is the only extent initially allocated. Even then you
can't tell the allocation units.

Query: does that change on an EAV?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
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...@listserv.ua.edu with the message: INFO IBM-MAIN




Såvida annat inte anges ovan: / Unless stated otherwise above:
IBM Svenska AB
Organisationsnummer: 556026-6883
Adress: 164 92 Stockholm

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


Re: Primary allocation of a dataset

2015-05-13 Thread Shmuel Metz (Seymour J.)
In , on 05/06/2015
   at 01:43 PM, Fred van der Windt 
said:

>I want to retrieve the primary allocation of a dataset.

You can't get that from the DSCB; the NVR has it for SMS datasets.
There is no indication in the VTOC as to which extent came from the
primary. The best that you can do is to look at the first extent and
hope that it is the only extent initially allocated. Even then you
can't tell the allocation units.

Query: does that change on an EAV?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
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...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Primary allocation of a dataset

2015-05-13 Thread Vernooij, CP (ITOPT1) - KLM
I don't know if it is, but I would be surprised if it is, because it is useless 
information for the system.
Furthermore, you know who created the data set and when, so you can find the 
JCL, Rexx of Dynalloc parameterlist that created the data set.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shmuel Metz (Seymour J.)
Sent: 11 May, 2015 14:49
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Primary allocation of a dataset

In
,
on 05/06/2015
   at 03:20 PM, Terry Sambrooks  said:

>As several people have already alluded IT IS NOT POSSIBLE to 
>retrieve the Primary Request for SPACE as it IS NOT recorded in 
>the DSCB.

That's true for non-SMS. What about the NVR?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
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...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Primary allocation of a dataset

2015-05-13 Thread Shmuel Metz (Seymour J.)
In <554a6683.90...@us.ibm.com>, on 05/06/2015
   at 03:07 PM, John Eells  said:

>At allocation time, the system converts anything other than tracks 
>to tracks, basically.

No; the system records wehther allocation is in tracks or in cylinders
so that it can correctly allocate secondary extents. For SMS datasets
there are also data in the NVR. 
 
-- 
 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...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Primary allocation of a dataset

2015-05-13 Thread Shmuel Metz (Seymour J.)
In
,
on 05/06/2015
   at 03:20 PM, Terry Sambrooks  said:

>As several people have already alluded IT IS NOT POSSIBLE to 
>retrieve the Primary Request for SPACE as it IS NOT recorded in 
>the DSCB.

That's true for non-SMS. What about the NVR?
 
-- 
 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...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Primary allocation of a dataset

2015-05-12 Thread willie bunter
Thanks for the suggestion.

On Tue, 5/12/15, Vernooij, CP (ITOPT1) - KLM  wrote:

 Subject: Re: Primary allocation of a dataset
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Tuesday, May 12, 2015, 2:22 AM
 
 Sure, the ACS routines
 determine where your dataset goes and if your request is
 honored or not. 
 You can bypass the ACS
 routines with the (IIRC) BYPASSACS parameter.
 
 Kees.
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of willie bunter
 Sent: 11 May,
 2015 19:10
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Primary allocation of a dataset
 
 I tried the example (JOB4)
 however it worked to a certain extent. All the dsns were
 moved to a volume othere than what was specified and  to a
 storage pool which is not  the same.  The dsns are SMS
 managed.  Could this be the reason?  Below is the job I
 ran:
 
 //STEP1    EXEC
 PGM=ADRDSSU                               
       
 //SYSPRINT
 DD   SYSOUT=*                       
                  
 //SYSIN    DD   *           
                                     
  COPY DATASET(         -     
                                
    
     INCLUDE(PROD03.**)) 
 /* FILTER ON DS W/1ST LEV Q USER1  */ - 
  
   OUTDYNAM(SLU340)    /* ALLOC VOL 338001 DYNAMICALLY 
   */ -  
     DELETE CATALOG FORCE -   
                                
    
      
    SPHERE                         
    -                    
          TGTALLOC(SOURCE)     
              -                   
 
          TGTGDS(SOURCE)   
                  -               
     
          CANCELERROR 
                       -                 
   
          OPT(4)       
                      -           
         
      
    ALLDATA(*) ALLEXCP                 
                     
 /*       
                                        
                
 
 On Wed, 5/6/15, Mike Schwab 
 wrote:
 
  Subject: Re:
 Primary allocation of a dataset
  To: IBM-MAIN@LISTSERV.UA.EDU
  Received: Wednesday, May 6, 2015, 8:44 PM
  
  To consolidate a multi
 volume dataset
  to one (or fewer)
 volume(s)
  
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.adru000/r2250.htm?lang=en
  
  //JOB4     JOB 
 accounting
  information,REGION=K
  //STEP1    EXEC PGM=ADRDSSU
 
 //SYSPRINT DD   SYSOUT=A
  //SYSIN   
 DD   *
   COPY DATASET(     
    -
     INCLUDE(data.set.name))  /*
 FILTER ON
  DS W/1ST LEV Q USER1  */ -
     OUTDYNAM(volser)    /* ALLOC VOL
  338001 DYNAMICALLY    */ -
 
    DELETE CATALOG FORCE -
 
    TGTALLOC(SOURCE)
  /*
 
 
  A single volume dataset you can just do a
 dataset
  consolidate.
  
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.adru000/cnsex.htm?lang=en
  
  //JOB1 
 
    JOB   accounting
 
 information,REGION=K
  //STEP1   
 EXEC  PGM=ADRDSSU
  //SYSPRINT DD   
 SYSOUT=A
  //DASD     DD   
  UNIT=3390,VOL=(PRIVATE,SER=volser),DISP=OLD
  //SYSIN    DD    *
  
    CONSOLIDATE DATASET(INCLUDE(data.set.name)
 -
       EXCLUDE(data.set.name)) -
       PHYSINDDNAME(DASD)
 
 /*
  
  On Wed, May 6, 2015 at
 5:21 PM, Paul Gilmartin
  <000433f07816-dmarc-requ...@listserv.ua.edu>
  wrote:
  > On 2015-05-06
 16:18, Mike Schwab wrote:
  >> I would
 be more worried about specifying enough
 
 space for the current
  >> contents and
 calculating a nice secondary space
  value. 
 10% for a 16
  >> extent type.  Maybe
 1% for a 1## extent type.
  >>
  > Oh, be done with it!  HMIGRATE it;
 HRECALL
  it.  HSM coalesces everything
  > into one neat extent and RLSEs everything
 else. 
  (But I wish there were a
  > way to achieve this with half the
 I/Os.)
  >
  > -- gil
  >
  >
 
 --
  > For IBM-MAIN subscribe / signoff /
 archive access
  instructions,
  > send email to lists...@listserv.ua.edu
  with the message: INFO IBM-MAIN
  
  
  
  -- 
  Mike A Schwab,
 Springfield IL USA
  Where do Forest Rangers
 go to get away from it all?
  
 
 --
  For IBM-MAIN subscribe / signoff / archive
 access
  instructions,
  send
 email to lists...@listserv.ua.edu
  with the message: INFO IBM-MAIN
  
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 
 For information, services and offers, please
 visit our web site: http://www.klm.com. This e-mail and any
 attachment may contain confidential and privileged material
 intended for the addressee only. If you are not the
 addressee, you are notified that no part of the e-mail or
 any attachment may be disclosed, copied or distributed, and
 that any ot

Re: Primary allocation of a dataset

2015-05-11 Thread Vernooij, CP (ITOPT1) - KLM
Sure, the ACS routines determine where your dataset goes and if your request is 
honored or not. 
You can bypass the ACS routines with the (IIRC) BYPASSACS parameter.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of willie bunter
Sent: 11 May, 2015 19:10
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Primary allocation of a dataset

I tried the example (JOB4) however it worked to a certain extent. All the dsns 
were moved to a volume othere than what was specified and  to a storage pool 
which is not  the same.  The dsns are SMS managed.  Could this be the reason?  
Below is the job I ran:

//STEP1EXEC PGM=ADRDSSU  
//SYSPRINT DD   SYSOUT=* 
//SYSINDD   *
 COPY DATASET( - 
INCLUDE(PROD03.**))  /* FILTER ON DS W/1ST LEV Q USER1  */ - 
OUTDYNAM(SLU340)/* ALLOC VOL 338001 DYNAMICALLY*/ -  
DELETE CATALOG FORCE -   
 SPHERE -
 TGTALLOC(SOURCE)   -
 TGTGDS(SOURCE) -
 CANCELERROR-
 OPT(4) -
 ALLDATA(*) ALLEXCP  
/*   

On Wed, 5/6/15, Mike Schwab  wrote:

 Subject: Re: Primary allocation of a dataset
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Wednesday, May 6, 2015, 8:44 PM
 
 To consolidate a multi volume dataset
 to one (or fewer) volume(s)
 
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.adru000/r2250.htm?lang=en
 
 //JOB4     JOB  accounting
 information,REGION=K
 //STEP1    EXEC PGM=ADRDSSU
 //SYSPRINT DD   SYSOUT=A
 //SYSIN    DD   *
  COPY DATASET(         -
    INCLUDE(data.set.name))  /* FILTER ON
 DS W/1ST LEV Q USER1  */ -
    OUTDYNAM(volser)    /* ALLOC VOL
 338001 DYNAMICALLY    */ -
    DELETE CATALOG FORCE -
    TGTALLOC(SOURCE)
 /*
 
 A single volume dataset you can just do a dataset
 consolidate.
 
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.adru000/cnsex.htm?lang=en
 
 //JOB1 
    JOB   accounting
 information,REGION=K
 //STEP1    EXEC  PGM=ADRDSSU
 //SYSPRINT DD    SYSOUT=A
 //DASD     DD   
 UNIT=3390,VOL=(PRIVATE,SER=volser),DISP=OLD
 //SYSIN    DD    *
 
   CONSOLIDATE DATASET(INCLUDE(data.set.name) -
      EXCLUDE(data.set.name)) -
      PHYSINDDNAME(DASD)
 /*
 
 On Wed, May 6, 2015 at 5:21 PM, Paul Gilmartin
 <000433f07816-dmarc-requ...@listserv.ua.edu>
 wrote:
 > On 2015-05-06 16:18, Mike Schwab wrote:
 >> I would be more worried about specifying enough
 space for the current
 >> contents and calculating a nice secondary space
 value.  10% for a 16
 >> extent type.  Maybe 1% for a 1## extent type.
 >>
 > Oh, be done with it!  HMIGRATE it; HRECALL
 it.  HSM coalesces everything
 > into one neat extent and RLSEs everything else. 
 (But I wish there were a
 > way to achieve this with half the I/Os.)
 >
 > -- gil
 >
 >
 --
 > For IBM-MAIN subscribe / signoff / archive access
 instructions,
 > send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 
 
 
 -- 
 Mike A Schwab, Springfield IL USA
 Where do Forest Rangers go to get away from it all?
 
 --
 For IBM-MAIN subscribe / signoff / archive access
 instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay

Re: Primary allocation of a dataset

2015-05-11 Thread willie bunter
I tried the example (JOB4) however it worked to a certain extent. All the dsns 
were moved to a volume othere than what was specified and  to a storage pool 
which is not  the same.  The dsns are SMS managed.  Could this be the reason?  
Below is the job I ran:

//STEP1EXEC PGM=ADRDSSU  
//SYSPRINT DD   SYSOUT=* 
//SYSINDD   *
 COPY DATASET( - 
INCLUDE(PROD03.**))  /* FILTER ON DS W/1ST LEV Q USER1  */ - 
OUTDYNAM(SLU340)/* ALLOC VOL 338001 DYNAMICALLY*/ -  
DELETE CATALOG FORCE -   
 SPHERE -
 TGTALLOC(SOURCE)   -
 TGTGDS(SOURCE) -
 CANCELERROR-
 OPT(4) -
 ALLDATA(*) ALLEXCP  
/*   

On Wed, 5/6/15, Mike Schwab  wrote:

 Subject: Re: Primary allocation of a dataset
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Wednesday, May 6, 2015, 8:44 PM
 
 To consolidate a multi volume dataset
 to one (or fewer) volume(s)
 
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.adru000/r2250.htm?lang=en
 
 //JOB4     JOB  accounting
 information,REGION=K
 //STEP1    EXEC PGM=ADRDSSU
 //SYSPRINT DD   SYSOUT=A
 //SYSIN    DD   *
  COPY DATASET(         -
    INCLUDE(data.set.name))  /* FILTER ON
 DS W/1ST LEV Q USER1  */ -
    OUTDYNAM(volser)    /* ALLOC VOL
 338001 DYNAMICALLY    */ -
    DELETE CATALOG FORCE -
    TGTALLOC(SOURCE)
 /*
 
 A single volume dataset you can just do a dataset
 consolidate.
 
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.adru000/cnsex.htm?lang=en
 
 //JOB1 
    JOB   accounting
 information,REGION=K
 //STEP1    EXEC  PGM=ADRDSSU
 //SYSPRINT DD    SYSOUT=A
 //DASD     DD   
 UNIT=3390,VOL=(PRIVATE,SER=volser),DISP=OLD
 //SYSIN    DD    *
 
   CONSOLIDATE DATASET(INCLUDE(data.set.name) -
      EXCLUDE(data.set.name)) -
      PHYSINDDNAME(DASD)
 /*
 
 On Wed, May 6, 2015 at 5:21 PM, Paul Gilmartin
 <000433f07816-dmarc-requ...@listserv.ua.edu>
 wrote:
 > On 2015-05-06 16:18, Mike Schwab wrote:
 >> I would be more worried about specifying enough
 space for the current
 >> contents and calculating a nice secondary space
 value.  10% for a 16
 >> extent type.  Maybe 1% for a 1## extent type.
 >>
 > Oh, be done with it!  HMIGRATE it; HRECALL
 it.  HSM coalesces everything
 > into one neat extent and RLSEs everything else. 
 (But I wish there were a
 > way to achieve this with half the I/Os.)
 >
 > -- gil
 >
 >
 --
 > For IBM-MAIN subscribe / signoff / archive access
 instructions,
 > send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 
 
 
 -- 
 Mike A Schwab, Springfield IL USA
 Where do Forest Rangers go to get away from it all?
 
 --
 For IBM-MAIN subscribe / signoff / archive access
 instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN


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


Re: Primary allocation of a dataset

2015-05-07 Thread Tony Harminc
On 6 May 2015 at 19:55, Webster, Chris  wrote:
> As was suggested before the extension contains the allocation amount 'type'.  
> DS1SCXTF contains the indicators for mega/kilo/bytes etc.  Old school (okay, 
> the usual) allocation request types are in DS1SCAL1.
>
> Is this what you are asking?

Yes, thanks. I hadn't kept up with the existence of DS1SCXTF and
friends. (Yeah, I know - it's from 1986...) All is clear now.

Tony H.

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


Re: Primary allocation of a dataset

2015-05-06 Thread Mike Schwab
To consolidate a multi volume dataset to one (or fewer) volume(s)
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.adru000/r2250.htm?lang=en

//JOB4 JOB  accounting information,REGION=K
//STEP1EXEC PGM=ADRDSSU
//SYSPRINT DD   SYSOUT=A
//SYSINDD   *
 COPY DATASET( -
   INCLUDE(data.set.name))  /* FILTER ON DS W/1ST LEV Q USER1  */ -
   OUTDYNAM(volser)/* ALLOC VOL 338001 DYNAMICALLY*/ -
   DELETE CATALOG FORCE -
   TGTALLOC(SOURCE)
/*

A single volume dataset you can just do a dataset consolidate.
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.adru000/cnsex.htm?lang=en

//JOB1 JOB   accounting information,REGION=K
//STEP1EXEC  PGM=ADRDSSU
//SYSPRINT DDSYSOUT=A
//DASD DDUNIT=3390,VOL=(PRIVATE,SER=volser),DISP=OLD
//SYSINDD*

  CONSOLIDATE DATASET(INCLUDE(data.set.name) -
 EXCLUDE(data.set.name)) -
 PHYSINDDNAME(DASD)
/*

On Wed, May 6, 2015 at 5:21 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On 2015-05-06 16:18, Mike Schwab wrote:
>> I would be more worried about specifying enough space for the current
>> contents and calculating a nice secondary space value.  10% for a 16
>> extent type.  Maybe 1% for a 1## extent type.
>>
> Oh, be done with it!  HMIGRATE it; HRECALL it.  HSM coalesces everything
> into one neat extent and RLSEs everything else.  (But I wish there were a
> way to achieve this with half the I/Os.)
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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


Re: Primary allocation of a dataset

2015-05-06 Thread Webster, Chris
As was suggested before the extension contains the allocation amount 'type'.  
DS1SCXTF contains the indicators for mega/kilo/bytes etc.  Old school (okay, 
the usual) allocation request types are in DS1SCAL1.

Is this what you are asking?

...chris.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Wednesday, May 06, 2015 4:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Primary allocation of a dataset

On 6 May 2015 at 16:54, Walt Farrell  wrote:
>>But how does it know what those original units were?
>
> DS1DSPAC shows you the original _units_ (trk, cyl, average block). As 
> far as I know (and as others have said) nothing will show you the 
> original _number_ of those units requested for the primary allocation, which 
> seems to be the OP's desire.

Sure - I get all that. But I don't know how ISPF displays 
cylinders/tracks/megabytes for various datasets. Is it just always displaying 
average blocks as megabytes? Maybe it's that simple; it's not something I've 
investigated - just noticed what seems like inconsistent output. Ah - maybe 
"megabytes" are only for PDSEs, even if they were allocated by tracks or 
cylinders. Well, no, I have a PDSE that shows current allocation in cylinders, 
so it's not that simple.

Tony H.

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

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


Re: Primary allocation of a dataset

2015-05-06 Thread Tony Harminc
On 6 May 2015 at 16:54, Walt Farrell  wrote:
>>But how does it know what those original units were?
>
> DS1DSPAC shows you the original _units_ (trk, cyl, average block). As far as 
> I know (and as others
> have said) nothing will show you the original _number_ of those units 
> requested for the primary
> allocation, which seems to be the OP's desire.

Sure - I get all that. But I don't know how ISPF displays
cylinders/tracks/megabytes for various datasets. Is it just always
displaying average blocks as megabytes? Maybe it's that simple; it's
not something I've investigated - just noticed what seems like
inconsistent output. Ah - maybe "megabytes" are only for PDSEs, even
if they were allocated by tracks or cylinders. Well, no, I have a PDSE
that shows current allocation in cylinders, so it's not that simple.

Tony H.

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


Re: Primary allocation of a dataset

2015-05-06 Thread Paul Gilmartin
On 2015-05-06 16:18, Mike Schwab wrote:
> I would be more worried about specifying enough space for the current
> contents and calculating a nice secondary space value.  10% for a 16
> extent type.  Maybe 1% for a 1## extent type.
> 
Oh, be done with it!  HMIGRATE it; HRECALL it.  HSM coalesces everything
into one neat extent and RLSEs everything else.  (But I wish there were a
way to achieve this with half the I/Os.)

-- gil

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


Re: Primary allocation of a dataset

2015-05-06 Thread Mike Schwab
I would be more worried about specifying enough space for the current
contents and calculating a nice secondary space value.  10% for a 16
extent type.  Maybe 1% for a 1## extent type.

On Wed, May 6, 2015 at 3:54 PM, Walt Farrell  wrote:
> On Wed, 6 May 2015 16:19:31 -0400, Tony Harminc  wrote:
>
>>On 6 May 2015 at 15:07, John Eells  wrote:
>>> I never actually checked, but I "assume" that ISPF and other things that
>>> show used space in allocation request units other than tracks or cylinders
>>> use the DS1DSPAC fields and track length to calculate space in those
>>> original request units.
>>
>>But how does it know what those original units were?
>
> DS1DSPAC shows you the original _units_ (trk, cyl, average block). As far as 
> I know (and as others have said) nothing will show you the original _number_ 
> of those units requested for the primary allocation, which seems to be the 
> OP's desire.
>
> Even ISPF does not claim to show you the _primary_ allocation. It shows, as 
> mentioned by the OP earlier, the value of the "1st extent". The primary 
> allocation is made up of a first extent and up to 4 other extents. ISPF just 
> shows the size of the first extent, which in many cases will be some value 
> less than or equal to the requested primary space. (But if adjacent extents 
> have been collapsed together it could, I suppose, be a value greater than the 
> requested primary space.)
>
> --
> Walt
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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


Re: Primary allocation of a dataset

2015-05-06 Thread Walt Farrell
On Wed, 6 May 2015 16:19:31 -0400, Tony Harminc  wrote:

>On 6 May 2015 at 15:07, John Eells  wrote:
>> I never actually checked, but I "assume" that ISPF and other things that
>> show used space in allocation request units other than tracks or cylinders
>> use the DS1DSPAC fields and track length to calculate space in those
>> original request units.
>
>But how does it know what those original units were?

DS1DSPAC shows you the original _units_ (trk, cyl, average block). As far as I 
know (and as others have said) nothing will show you the original _number_ of 
those units requested for the primary allocation, which seems to be the OP's 
desire.

Even ISPF does not claim to show you the _primary_ allocation. It shows, as 
mentioned by the OP earlier, the value of the "1st extent". The primary 
allocation is made up of a first extent and up to 4 other extents. ISPF just 
shows the size of the first extent, which in many cases will be some value less 
than or equal to the requested primary space. (But if adjacent extents have 
been collapsed together it could, I suppose, be a value greater than the 
requested primary space.)

-- 
Walt

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


Re: Primary allocation of a dataset

2015-05-06 Thread Fred van der Windt
When you allocatie a dataset you specify space (blocks, tracks cylinders, MB or 
whatever) and a primary and secondary amount. The space and secondary amount is 
preserved in The DSCB1/8. The space was also used to allocate the primary 
extent(s). It is just the primary amount (as specified in the allocation 
command) that does not seem to be available anymore.

Fred!

Sent from my new iPad

> On May 6, 2015, at 22:19, Tony Harminc  wrote:
> 
>> On 6 May 2015 at 15:07, John Eells  wrote:
>> I never actually checked, but I "assume" that ISPF and other things that
>> show used space in allocation request units other than tracks or cylinders
>> use the DS1DSPAC fields and track length to calculate space in those
>> original request units.
> 
> But how does it know what those original units were?
> 
> Tony H.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

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


Re: Primary allocation of a dataset

2015-05-06 Thread Tony Harminc
On 6 May 2015 at 15:07, John Eells  wrote:
> I never actually checked, but I "assume" that ISPF and other things that
> show used space in allocation request units other than tracks or cylinders
> use the DS1DSPAC fields and track length to calculate space in those
> original request units.

But how does it know what those original units were?

Tony H.

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


Re: Primary allocation of a dataset

2015-05-06 Thread John Eells

fred.van.der.wi...@mail.ing.nl (Fred van der Windt) wrote:

I want to retrieve the primary allocation of a dataset. Sofar I've used OBTAIN 
to retrieve the DCSBs for the dataset. The DSCB1 contains information about the 
secondary allocation size for the dataset but does not contain any information 
about the primary allocation. If the dataset had a primary allocation in tracks 
or cylinders I can retrieve the necessary information from the extent 
information in the DSCB1: the first extent can be converted back to tracks or 
cylinders and that should be the primary allocation.

But how can one recreate the primary allocation if some other form was used, 
for instance an amount in blocks, records or KB or something like that? Is this 
documented anywhere?


As I think you found, the primary allocation is represented in the F1 or 
F8 DSCB by DS1EXT1 and following fields, and perhaps by "extension 
DSCBs" that contain additional extent descriptions, which if present 
should be pointed to by DS1PTRDS.


So far as allocation units go, what is in DSCBs is cylinder and head 
(track) information.  Eventually, it all boils down to the physical 
allocation units* the system supports for data sets, which are tracks, 
though you can choose to begin allocation on a cylinder boundary (which 
is indicated by DS1CYL) and allocate in numbers of cylinders, or use 
other units the system supports for the specification of disk space.  At 
allocation time, the system converts anything other than tracks to 
tracks, basically.  The type of specification is saved, but not used.


I never actually checked, but I "assume" that ISPF and other things that 
show used space in allocation request units other than tracks or 
cylinders use the DS1DSPAC fields and track length to calculate space in 
those original request units.  These are necessarily fuzzy numbers for 
some kinds of data sets in comparison to the actual numbers of blocks 
contained or the actual number of KB or MB actually written.  I think 
they're about as useful as they can be when allocating a new data set 
using the same number the tool displays yields the same size data set as 
the original (smile), and I believe this to be the case for ISPF a very 
high percentage of the time (if not 100% of the time).


How much of this is documented?  No idea...

* Not truly physical any more, post-3390, but rather emulated on modern 
disk; however, the logical architecture remains the same even though the 
physical layer varies underneath it.


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

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


Re: Primary allocation of a dataset

2015-05-06 Thread Vernooij, CP (ITOPT1) - KLM
Even in the case of CONTIG, allocation would create the primary space as 
requested, but subsequent merged contiguous extents and/or the RLSE option, 
could also leave behind a different primary extent after CLOSE.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Terry Sambrooks
Sent: 06 May, 2015 16:21
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Primary allocation of a dataset

Hi 

As several people have already alluded IT IS NOT POSSIBLE to retrieve the
Primary Request for SPACE as it IS NOT recorded in the DSCB.

There is no need to store this information as it is either available and
used or it is not in which case the data set is not created. The Secondary
Request has to be stored in the DSCB for subsequent use if the need arises.

The FIRST EXTENT will only equate to the Primary Request if CONTIG were
specified at allocation time. If CONTIG is not specified then the system
will attempt to allocate the Primary in up to 5 extents. When LISTDSI and
ISPF 3.2 are used they only report the first extent, which may only be a
subset of the Primary Request.

Kind Regards - Terry
 
Director
KMS-IT Limited
228 Abbeydale Road South
Dore
Sheffield
S17 3LA
UK
 
Reg : 3767263
 
Outgoing e-mails have been scanned, but it is the recipients responsibility
to ensure their anti-virus software is up to date.
 
 


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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Primary allocation of a dataset

2015-05-06 Thread Terry Sambrooks
Hi 

As several people have already alluded IT IS NOT POSSIBLE to retrieve the
Primary Request for SPACE as it IS NOT recorded in the DSCB.

There is no need to store this information as it is either available and
used or it is not in which case the data set is not created. The Secondary
Request has to be stored in the DSCB for subsequent use if the need arises.

The FIRST EXTENT will only equate to the Primary Request if CONTIG were
specified at allocation time. If CONTIG is not specified then the system
will attempt to allocate the Primary in up to 5 extents. When LISTDSI and
ISPF 3.2 are used they only report the first extent, which may only be a
subset of the Primary Request.

Kind Regards - Terry
 
Director
KMS-IT Limited
228 Abbeydale Road South
Dore
Sheffield
S17 3LA
UK
 
Reg : 3767263
 
Outgoing e-mails have been scanned, but it is the recipients responsibility
to ensure their anti-virus software is up to date.
 
 


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


Re: Primary allocation of a dataset

2015-05-06 Thread Lizette Koehler
There are probably several items on cbttape.org that may already do some of
what you are looking to do.

What problem are you trying to solve?  Would it be better to use something
already created or are you looking to understand some function better?

REXX has some built-ins, SAS has some functions, ISPF Services, and so
forth.

Could you provide more details on what is driving this question?  There
might be better solutions.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Fred van der Windt
> Sent: Wednesday, May 06, 2015 4:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Primary allocation of a dataset
> 
> I want to retrieve the primary allocation of a dataset. Sofar I've used
OBTAIN
> to retrieve the DCSBs for the dataset. The DSCB1 contains information
about
> the secondary allocation size for the dataset but does not contain any
> information about the primary allocation. If the dataset had a primary
> allocation in tracks or cylinders I can retrieve the necessary information
from
> the extent information in the DSCB1: the first extent can be converted
back
> to tracks or cylinders and that should be the primary allocation.
> 
> But how can one recreate the primary allocation if some other form was
> used, for instance an amount in blocks, records or KB or something like
that?
> Is this documented anywhere?
> 
> Fred!

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


Re: Primary allocation of a dataset

2015-05-06 Thread Staller, Allan
That is *NOT NECESSARILY* the primary allocation. That is the *current*  
allocation of the 1st extent. This may have been changed by SMS, Allocation 
space-(xx,rlse) or other.
As was previously stated, once the dataset has been successfully created, the 
amount of primary space requested is no longer available.


> You will never be able to determine the original primary allocation 
> amount, because it is not recorded. When the primary allocation is 
> done, it can be done in one or more extents and adjacent secondary 
> extents can be merged together into 1 extent. Furthermore after close 
> of the dataset, idle space can be released. From that moment on, all 
> what is left is the status of the dataset at that moment, which is the 
> result of any or all of the above actions, but you cannot determine the 
> requested primary allocation from it.

The strange part is that TSO 3.2 option seems to be able to recreate this info. 
If I allocate a dataset with a recordlength and blocksize of 100 bytes, a 
primary allocation of 14 KB and a secondary allocation of 2KB it is reported as:

1st extent kilobytes: 14
Secondary kilobytes : 2

Current Allocation
Allocated kilobytes : 14
Allocated extents . : 1

The DSCBs in the VTOC contains a secondary allocation of 2K and an allocation 
in one extent of 2 tracks. Where did 3.2 find my primary allocation of 14K?


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


Re: Primary allocation of a dataset

2015-05-06 Thread Roberto Halais
I don't know if this is what the OP wants.

I have a rexx utility that uses: X = CALL LISTDSI(DSNAME DIRECTORY SMSINFO
NORECALL)

and I get back:

DSNAME==>  SYSPROG.CBT.FILE805.LIB
VOLSER==>  COS101
DSORG ==>  PO   TYPE ==>  PDS
RECFM ==>  FB   SEQ TYPE ==>
LRECL ==>  80
BLKSIZE   ==>  5600
DIR BLKS  ==>  10
USED DIR B==>  5
MEMBERS   ==>  29
ALLOC UNIT==>  BLOCK
ALLOC ==>  234
USED  ==>  180
USED PAGES==> PDSE USED 4K PAGES
EXTENTS   ==>  1
PRIMARY   ==>  234
SECONDARY ==>  58
UNIT  ==>  3390   Tracks/Cyl: 15  Blks/TRK: 9
CRE DATE  ==>  05/05/2015
REF DATE  ==>  05/06/2015
UPDATED   ==>  YES
SAF Prof  ==>  GENERIC

On Wed, May 6, 2015 at 8:11 AM, Vernooij, CP (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:

> You will never be able to determine the original primary allocation
> amount, because it is not recorded. When the primary allocation is done, it
> can be done in one or more extents and adjacent secondary extents can be
> merged together into 1 extent. Furthermore after close of the dataset, idle
> space can be released. From that moment on, all what is left is the status
> of the dataset at that moment, which is the result of any or all of the
> above actions, but you cannot determine the requested primary allocation
> from it.
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Fred van der Windt
> Sent: 06 May, 2015 13:43
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Primary allocation of a dataset
>
> I want to retrieve the primary allocation of a dataset. Sofar I've used
> OBTAIN to retrieve the DCSBs for the dataset. The DSCB1 contains
> information about the secondary allocation size for the dataset but does
> not contain any information about the primary allocation. If the dataset
> had a primary allocation in tracks or cylinders I can retrieve the
> necessary information from the extent information in the DSCB1: the first
> extent can be converted back to tracks or cylinders and that should be the
> primary allocation.
>
> But how can one recreate the primary allocation if some other form was
> used, for instance an amount in blocks, records or KB or something like
> that? Is this documented anywhere?
>
> Fred!
> -
> ATTENTION:
> The information in this electronic mail message is private and
> confidential, and only intended for the addressee. Should you
> receive this message by mistake, you are hereby notified that
> any disclosure, reproduction, distribution or use of this
> message is strictly prohibited. Please inform the sender by
> reply transmission and delete the message without copying or
> opening it.
>
> Messages and attachments are scanned for all viruses known.
> If this message contains password-protected attachments, the
> files have NOT been scanned for viruses by the ING mail domain.
> Always scan attachments before opening them.
> -
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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


Re: Primary allocation of a dataset

2015-05-06 Thread Fred van der Windt
> You will never be able to determine the original primary allocation amount,
> because it is not recorded. When the primary allocation is done, it can be
> done in one or more extents and adjacent secondary extents can be merged
> together into 1 extent. Furthermore after close of the dataset, idle space can
> be released. From that moment on, all what is left is the status of the 
> dataset
> at that moment, which is the result of any or all of the above actions, but 
> you
> cannot determine the requested primary allocation from it.

The strange part is that TSO 3.2 option seems to be able to recreate this info. 
If I allocate a dataset with a recordlength and blocksize of 100 bytes, a 
primary allocation of 14 KB and a secondary allocation of 2KB it is reported as:

1st extent kilobytes: 14
Secondary kilobytes : 2

Current Allocation
Allocated kilobytes : 14
Allocated extents . : 1

The DSCBs in the VTOC contains a secondary allocation of 2K and an allocation 
in one extent of 2 tracks. Where did 3.2 find my primary allocation of 14K?

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

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


Re: Primary allocation of a dataset

2015-05-06 Thread Vernooij, CP (ITOPT1) - KLM
You will never be able to determine the original primary allocation amount, 
because it is not recorded. When the primary allocation is done, it can be done 
in one or more extents and adjacent secondary extents can be merged together 
into 1 extent. Furthermore after close of the dataset, idle space can be 
released. From that moment on, all what is left is the status of the dataset at 
that moment, which is the result of any or all of the above actions, but you 
cannot determine the requested primary allocation from it.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Fred van der Windt
Sent: 06 May, 2015 13:43
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Primary allocation of a dataset

I want to retrieve the primary allocation of a dataset. Sofar I've used OBTAIN 
to retrieve the DCSBs for the dataset. The DSCB1 contains information about the 
secondary allocation size for the dataset but does not contain any information 
about the primary allocation. If the dataset had a primary allocation in tracks 
or cylinders I can retrieve the necessary information from the extent 
information in the DSCB1: the first extent can be converted back to tracks or 
cylinders and that should be the primary allocation.

But how can one recreate the primary allocation if some other form was used, 
for instance an amount in blocks, records or KB or something like that? Is this 
documented anywhere?

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Primary allocation of a dataset

2015-05-06 Thread Fred van der Windt
I want to retrieve the primary allocation of a dataset. Sofar I've used OBTAIN 
to retrieve the DCSBs for the dataset. The DSCB1 contains information about the 
secondary allocation size for the dataset but does not contain any information 
about the primary allocation. If the dataset had a primary allocation in tracks 
or cylinders I can retrieve the necessary information from the extent 
information in the DSCB1: the first extent can be converted back to tracks or 
cylinders and that should be the primary allocation.

But how can one recreate the primary allocation if some other form was used, 
for instance an amount in blocks, records or KB or something like that? Is this 
documented anywhere?

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

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