All of our DB2 data bases are managed by SMS. What is puzzeling is the DBAs are saying this worked fine in z/OS V1.7 but with the installation of z/OS V1.9 it is failing. I am looking in IBM Link and not finding anything that would support that view.
But I will try setting up the DC routine to use VOL 10 for these files. Lizette > >It should but the file must be SMS managed. > >________________________________ > >From: Lizette Koehler [mailto:[EMAIL PROTECTED] >Sent: Mon 8/25/2008 4:24 PM >To: IBM-MAIN@BAMA.UA.EDU >Subject: Re: Platinum and z/OS V1.9 > > > >Would that force Platinum to use more '*'? > >Currently the dataclas for this data is (NULL). > >Lizette > > > >>Lizette, >> >> You might consider using a Data class that has the following attributes: >> >>Space Constraint Relief . . . : YES >> Reduce Space Up To (%) . . : 30 >> Dynamic Volume Count . . . : 9 >> >>Regards, >>Dave O'Brien >> >>________________________________ >> >>From: Lizette Koehler [mailto:[EMAIL PROTECTED] >>Sent: Mon 8/25/2008 4:11 PM >>To: IBM-MAIN@BAMA.UA.EDU >>Subject: Platinum and z/OS V1.9 >> >> >> >>Cross posting to IBMMAIN and DB2 Newsgroups >> >> >> >>Are there any issues with DB2 V8, Platinum and z/OS V1.9? >> >>Our DBA group is indicating that since the z/OS V1.9 operating system went >>in, the Platinum loads have failed on space issues. >> >>What they are seeing are: >> >>IGD17226I THERE IS AN INSUFFICIENT NUMBER OF VOLUMES IN THE ELIGIBLE >> >>STORAGE GROUP(S) TO SATISFY THIS REQUEST FOR DATA SET >> >>TSTDSN1.DSNDBC.DSN1005.DSN1XXOE.I0001.A001 >> >>IGD17290I THERE WERE 1 CANDIDATE STORAGE GROUPS OF WHICH THE FIRST 1 >> >>WERE ELIGIBLE FOR VOLUME SELECTION. >> >>THE CANDIDATE STORAGE GROUPS WERE:TST1 >> >>IGD17279I 88 VOLUMES WERE REJECTED BECAUSE THE SMS VOLUME STATUS WAS DISABLED >> >>IGD17279I 133 VOLUMES WERE REJECTED BECAUSE OF INSUFF TOTAL SPACE >> >>IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET >> >>TSTDSN1.DSNDBC.DSN1005.DSN1XXOE.I0001.A001 >> >>IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 >> >> >> >>IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 12 >> >> >> >> DEFINE CLUSTER (NAME(TSTDSN1.DSNDBC.DSN1005.DSN1XXOE.I0001.A001 ) - >> >> LINEAR REUSE SPEED SHAREOPTIONS(3 3) ) - >> >> DATA (NAME(TSTDSN1.DSNDBD.DSN1005.DSN1XXOE.I0001.A001 ) - >> >> RECORDS( 000297000,000090000) - >> >> CONTROLINTERVALSIZE(000032768) - >> >> VOLUMES(* )) >> >> >> >>My recommendation is to add more asterisks to the VOLUME statement. We have >>at least 6 volumes that can handle the primary allocation. And if I >>calculated it correctly it is 1650 Cylinders Primary and 500 cylinders >>secondary. What I believe to be happening is that due to the one asterisk is >>causing the failure and if it had more it might make it. >> >>My questions: >> >>1) Can you alter the define in Platinum to use more asterisks? >>2) Is there a change in z/OS V1.9 that makes storage allocation more >>difficult with DFSMS? Any ACS or other changes needed to alter the behavior? >> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
