Expand database for multi-volume use
search cancel

Expand database for multi-volume use

book

Article ID: 271020

calendar_today

Updated On:

Products

MICS Resource Management

Issue/Introduction

Our daily job abended and the MONTHLY database is full and using an entire Mod 9 volume.  We don't have a Mod 27 available.

Can the MONTHLY database expand to multi-volume usage?

 

 

Environment

Release : 14.2

Resolution

Yes, you can expand the database to multi-volume use. 

Step 1)  Allocate new monthly DSN with VOL GT 1. (as new name, like prefix.MONTH.NEW)

Step 2)  Use SAS PROC COPY to copy SAS DSN from full DSN to new DSN

Step 3)  Rename old "FULL" DSN to prefix.MONTHS.OLD

Step 4)  Rename new multivolume DSN to prefix.MONTHS

Then restart the job that failed.

 

Additional Information

Provided below is a sample MICS/SAS jobstream that copies a MICS time-span based on specified (optimal)  JCL DD parameters. 
This uses JCL SET symbols to help externalize those JCL DD parameters deemed “conditional”:

//JOBNAME JOB (ACCT), 'PGMR-NAME',CLASS=?,MSGCLASS=?,
//  NOTIFY=&SYSUID,TIME=NOLIMIT
//* */
//* SAMPLE MICS/SAS JCL JOBSTREAM USED TO COPY A MICS TIME-SPAN
//*   BASED ON SPECIFIED (OPTIMAL) JCL DD PARAMETERS
//* */
//         JCLLIB ORDER=MICS.PROCLIB
//         SET COPYDSN='MICS.DB.MONTHS'
//         SET SPCALLOC='8000,4000'
//         VOLCNT=10
//* */
//RESTCOPY EXEC MICSNDB?   <== CHOOSE MICS UNIT DB HERE ==
//IN       DD   DISP=OLD,DSN=&COPYDSN
//OUT      DD   DSN=COPYDSN..NEW,
// DISP=(NEW,CATLG,DELETE),
// DSNTYPE=LARGE,
// UNIT=(SYSDA,&VOLCNT),SPACE=(CYL,(&SPCALLOC))
//SYSIN    DD   DATA,DLM=ZZ
PROC COPY CLONE DATECOPY IN=IN OUT=OUT;
RUN;
ZZ
//* */
//VERIFY   EXEC MICSNDB?  <== SAME MICS UNIT DB HERE ==
//PDB      DD   DISP=OLD,DSN=&COPYDSN..NEW
//SYSIN    DD   DATA,DLM=ZZ
OPTIONS SOURCE SOURCE2 NOCENTER LS=MAX;
PROC CONTENTS DATA=PDB._ALL_;
RUN;
ZZ
//* */

Do consider that the “secondary SPACE” amount is used by z/OS for the “primary amount” for each additional DASD volume beyond the first one.
In addition, DSNTYPE=LARGE is required for any attempt to allocate a volume-extent that goes beyond the z/OS legacy amount of 65,535 tracks (equivalent to 4039 cylinders).
It is best to allocate a large secondary-amount since the z/OS legacy extents-limit per volume is 16 and that cannot change.

It is also worth considering migrating the MICS/SAS databases to: 1) SMS managed storage, 2) DASD technology, such as 3390 MOD54 or EAVs.  
With tape-directed output files, we strongly suggest that a VTS technology solution be considered where output tape-storage can exploit higher (virtual) GB capacity, such as using SMS DATACLAS like DC25GB (must be site-configured, based on IBM Hydra/TS7700 configuration example).  This can greatly reduce the MICS operational job(s) (like DAILY, WEEKLY, MONTHLY, AUDIT, HISTW, HISTM, BACKUP, MBACKUP elapsed time where large output SAS sequential-format databases are written.)