On Tue, May 10, 2016 at 7:35 AM, Leopold Strauss < [email protected]> wrote:
> Hi, all, > > A customer from my company gets following error-message during restore of > a ADRDSSU-dump-dataset: > > *ADR472E (001)-NEWDS(06), UNABLE TO SELECT A TARGET VOLUME FOR DATA SET > xx.yy.zz, *72*).* > > The explanation for 72 is: > > *During a non-SMS allocation, no target volumes were available and at > least one output volume was not selected because it was SMS-managed.* > > The used JCL-output-dd-statement: > > //OUTDD DD UNIT=SYSALLDA,DISP=(,CATLG,CATLG),SPACE=(TRK,(2000,900)) > This DD simply looks weird to me. When I want to restore to a non-SMS volume, I select the exact volume that I want and use the JCL //OUTDD DD DISP=SYSALLDA,DISP=OLD,VOL=SER=volser Without knowing both the DASD mount status of their volumes and the customer's ACS routines, I can't say for certain whether the OUTDD will select a PUBLIC/STORAGE mounted non-SMS volume or if the ACS routines will see that it is for a temporary data set and allocate it to an SMS manage storage group which is used for temporary data sets (this is what the ACS routines here would do). In addition, the given JCL will select a volume which has at least 2000 tracks on it, but then will "use up" those tracks and thus perhaps "use up" all the available space on that volume. Most unusual and confusing to me. > > The used commands( I changed datasetnames): > > RESTORE - > DATASET (INCLUDE( - > aaaaaa.bbbbbb.** - > aaaaaa.cccccc.** - > aaaaaa.yyyyyy.** - > aaaaaa.xxxxxxxx.** - > aaaaaa.zzzzzz.** - > ) - > ) - > INDDNAME(INDD) - > OUTDDNAME(OUTDD) - > RENAMEUNCONDITIONAL( - > (aaaaaa.bbbbbb.1111 - > NEW.bbbbbb.1111 ) - > (aaaaaa.bbbbbb.22222 - > NEW.bbbbbb.22222 ) - > (aaaaaa.cccccc.33333 - > NEW.cccccc.33333 ) - > (aaaaaa.bbbbbb.44444 - > ............................ > > NEW is a sysnonym for customer's prefix. > > Syntax of statements is OK. > > > *During a non-SMS allocation, no target volumes were available and at > least one output volume was not selected because it was SMS-managed.* > > But what does that explanation really mean in detail? > > What can I suggest to customer? > > thx in advance > > > Leo > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- The unfacts, did we have them, are too imprecisely few to warrant our certitude. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
