Reacjing the Limits of Volumes.

We have some DB’s that have almost 59 Volumes , per DSN.
We can overcome the Limit either by

  1. ADDing a new DSN as DDASSOR2 / DDDATAR2 ?
    or
  2. Moving to Device 3390-9 and above ,
    so we have more Cylinders on every volume.

Which option is preferred ?
Do you have info about other customers’ preference ?
Please let us know the pros and cons for these options.

If you have available to you the ability to use large volumes (3390-9 and above), then there is no reason not to go that route (assuming such volumes are supported.

I have also dealt with adding a second container for ASSO and DATA… that works too though then you must change all your JCL to have the DDASSOR2 and DDDATAR2 coded… minor inconvenience.

Be sure you are also using alternate device types such as 8391, 8392 or 8393, whichever will help you use the space on a 3390 type device most efficiently.

a tad late but still might be interesting to see what we’ve done :slight_smile:

before:
P H Y S I C A L L A Y O U T

DD- I DEV I NMBR OF I NMBR OF EXTENTS IN BLK. I BLOCK I NMBR OF I
NAMES I TYPE I CYLS I BLOCKS FROM TO I LNGTH I M-BYTE I
I I I I I I
-------I------I---------I----------------------------------I-------I----------I
I I I I I I
ASSOR1 I 8392 I 133200 I 23975988 1 23975988 I 4092 I 93564 I
ASSOR2 I 8392 I 33300 I 5994000 23975989 29969988 I 4092 I 23391 I
I I I I I I
DATAR1 I 8392 I 196470 I 11788196 1 11788196 I 12796 I 143853 I
DATAR2 I 8392 I 79920 I 4795200 11788197 16583396 I 12796 I 58516 I
DATAR3 I 8392 I 59940 I 3596400 16583397 20179796 I 12796 I 43887 I
I I I I I I
WORKR1 I 8392 I 1700 I 76497 1 76497 I 18452 I 1346 I
I I I I I I

after:

P H Y S I C A L L A Y O U T

DD- I DEV I NMBR OF I NMBR OF EXTENTS IN BLK. I BLOCK I NMBR OF I
NAMES I TYPE I CYLS I BLOCKS FROM TO I LNGTH I M-BYTE I
I I I I I I
-------I------I---------I----------------------------------I-------I----------I
I I I I I I
ASSOR1 I 8392 I 590944 I 106369908 1 106369908 I 4092 I 415101 I
I I I I I I
DATAR1 I 8392 I 590944 I 35456636 1 35456636 I 12796 I 432685 I
I I I I I I
WORKR1 I 8392 I 1700 I 76497 1 76497 I 18452 I 1346 I
I I I I I I

And we use JCLLIBs to minimise the impact of changing too many jobs:

e.g.

before:
-IPT- EDIT PADA.CNTL(DSETX) - 01.04
Command ===>
****** ***************************** Top of Data **********
000001 //DDASSOR1 DD DSN=PADA.DB.ASSO.V180600,DISP=SHR
000002 //DDASSOR2 DD DSN=PADA.DB.ASSO2.V211104,DISP=SHR
000003 //DDDATAR1 DD DSN=PADA.DB.DATA.V180600,DISP=SHR
000004 //DDDATAR2 DD DSN=PADA.DB.DATA2.V150902,DISP=SHR
000005 //DDDATAR3 DD DSN=PADA.DB.DATA3.V211104,DISP=SHR
000006 //DDWORKR1 DD DSN=PADA.DB.WORK.V180600,DISP=SHR
****** **************************** Bottom of Data ********

after:
-IPT- EDIT PADA.CNTL(DSET) - 01.00
Command ===>
****** ***************************** Top of Data ********
000001 //DDDATAR1 DD DSN=PADA.DB.DATA.V281008,DISP=SHR
000002 //DDASSOR1 DD DSN=PADA.DB.ASSO.V281008,DISP=SHR
000003 //DDWORKR1 DD DSN=PADA.DB.WORK.V180600,DISP=SHR

always:
//ADADBdb PROC PRM=DBPARM,DSF=N,UTIL=N
//ADABAS EXEC PGM=ADARUN,REGION=300M,TIME=1440
//STEPLIB DD DSN=ADABAS.ADA744.LOAD,DISP=SHR
//JOBEND INCLUDE MEMBER=DSET
//DBPLOG INCLUDE MEMBER=DNLOG&UTIL
//DDCLOGR1 DD DSN=PADA.DB.CLOG1.V180600,DISP=SHR
//DDCLOGR2 DD DSN=PADA.DB.CLOG2.V180600,DISP=SHR
//DDCARD DD DSN=PADA.DATA.DDCARD(&PRM),DISP=SHR

Oops, I should have added an example DD from the ADAFM:
//DDASSOR1 DD DSN=PADA.DB.ASSO.V281008,DISP=(NEW,CATLG),UNIT=SYSDA,
// SPACE=(CYL,(10016,10016)),DSNTYPE=LARGE,
// VOL=SER=(PA33A1,PA33A2,PA33A3,PA33A4,PA33A5,PA33A6,PA33A7,
// PA33A8,PA33A9,PA33AA,PA33AB,PA33AC,PA33AD,PA33AE,PA33AF,
// PA33AG,PA33AH,PA33AI,PA33AJ,PA33AK,PA33AL,PA33AM,PA33AN,
// PA33AO,PA33AP,PA33AQ,PA33AR,PA33AS,PA33AT,PA33AU,PA33AV,
// PA33AW,PA33AX,PA33AY,PA33AZ,PA33B1,PA33B2,PA33B3,PA33B4,
// PA33B5,PA33B6,PA33B7,PA33B8,PA33B9,PA33BA,PA33BB,PA33BC,
// PA33BD,PA33BE,PA33BF,PA33BG,PA33BH,PA33BI,PA33BJ,PA33BK,
// PA33BL,PA33BM,PA33BN,PA33BO)