Page 1 of 1

DFSMS and system generated temporary dataset names

PostPosted: Wed Jul 20, 2011 6:45 pm
by Peter_Mann
I seem to remember, in the DFP days prior to DFSMS, that system generated datasets, true temporary datasets (SYS11198.T080046.RA000.**) would be directed to volumes mounted PUBLIC, and due to this fact, datasets cannot be cataloged, and at the end of the task or at system shutdown, the datasets were deallocated, thus removed from the volume(s).
I've taken over at the Storage Admin, and I'm noticing these datasets are being directed to an SMS STORCLAS and a POOL of volumes, this is OK, but these datasets are not being cleaned up. I've looked at the SMS STORCLAS,STORGRP constructs and I cannot see a setting or a way to tell SMS to deallocate, clean these datasets up after task ends. The person who wrote the routines have these datasets going to the same STORCLAS as all other datasets "STANDARD" and the STORGRP routine decides where to direct these datasets.
WHEN (&DSTYPE = 'TEMP')                 /* TEMP DATA SETS TO      *
  DO                                    /* TEMPPOOL STORAGE GRP.  *
    IF (&STORCLAS = 'LCLNATVE')                                   
      THEN DO                                                     
             SET &STORGRP='LCLNATVE'                               
             EXIT CODE(0)                                         
           END                                                     
      ELSE DO                                                     
             SET &STORGRP='DPTPPOOL'                               
             EXIT CODE(0)                                         
           END                                                     
  END                                                             


I have modified the routines from what I've done at a previous shop, but I'm not sure if I'll get the results I desire.
Amy question is; do all SMS managed VOLUMES have to be mounted PRIVATE? can I still mount them PUBLIC?
below is the code I've modified to ahndle temporary datssets and vio allocation.
    IF (&DSTYPE = 'TEMP' && &UNIT = &VIOUNT)                 
      THEN DO                                                 
    SELECT                                                   
      WHEN (&DSORG = 'VS') SET &STORCLAS = 'SCTEMP'           
    OTHERWISE                                                 
       SET &STORCLAS = 'SCVIO'                               
     END                                                     
      EXIT CODE(0)                                           
     END                                                     

and the storgrp code does
 WHEN (&STORCLAS = 'SCTEMP')   
   DO                         
   SET &STORGRP = 'SGTEMP'     
     EXIT CODE(0)             

but I still don't know if these datasets will automagically clean themselves up, any help would be appricated, thanks
Peter

Re: DFSMS and system generated temporary dataset names

PostPosted: Wed Jul 20, 2011 8:53 pm
by Robert Sample
Peter:
but these datasets are not being cleaned up.
is this ALL of them, or just some of them? If it is just some of them, the started tasks and long-running tasks will keep these datasets out there until they end.

Re: DFSMS and system generated temporary dataset names

PostPosted: Wed Jul 20, 2011 9:47 pm
by Peter_Mann
Hi Bob,
The ADABAS, BROKER, and some other database regions come down every night, so I wanted to assume (I know bad...) that thier temporary datasets would get cleaned up, ACF2 and some other tasks that do not get shutdown until IPL time, even then I wanted to think I'd never see these datasets hanging around after an IPL. I'm gonna test (on a test LPAR) mounting the temp dasd pool as PUBLIC and see what the repercussions are, what's your thought?
Peter

Re: DFSMS and system generated temporary dataset names

PostPosted: Wed Jul 20, 2011 10:44 pm
by mikereis
The volume mount attribute is ignored by SMS. There are times and conditions that will cause temps to be stranded after a job ends and there are ways to clean these up. Sorry but I don't recall off the top of my head and I don't really have time to research this. Perhaps one of the Storage guys on here can answer this.

Re: DFSMS and system generated temporary dataset names

PostPosted: Wed Jul 20, 2011 10:51 pm
by Peter_Mann
Thanks Mike, I appricate your response and time.
I do have a process to list the VTOC and create DELETE NVR IDCAMS control cards, based on certain criteria, just thinking the SMS contructs were maybe missing a setting or paramater that's keeping these temps as.....perms..
again thanks

Peter

Re: DFSMS and system generated temporary dataset names

PostPosted: Thu Jul 21, 2011 2:07 am
by dick scherrer
Hello,

Hi Bob,
Robert please, rather than Bob. . . ;)

d

Re: DFSMS and system generated temporary dataset names

PostPosted: Thu Jul 21, 2011 5:56 pm
by expat
Peter,

I think that you will find that the majority of temp datasets get deleted as you would expect, else you would be having all sorts of space issues all of the time.

Take a look at IEHPROGM as that can be used to delete these datasets, he says from memory.

Re: DFSMS and system generated temporary dataset names

PostPosted: Thu Jul 21, 2011 8:23 pm
by Peter_Mann
dick scherrer wrote:Hello,

Hi Bob,
Robert please, rather than Bob. . . ;)

d

so sorry Robert
Peter

Re: DFSMS and system generated temporary dataset names

PostPosted: Thu Jul 21, 2011 8:26 pm
by Peter_Mann
expat wrote:Peter,

I think that you will find that the majority of temp datasets get deleted as you would expect, else you would be having all sorts of space issues all of the time.

Take a look at IEHPROGM as that can be used to delete these datasets, he says from memory.

Thanks for the jogg :idea: of my memory, I'll change my process to create and use IEHPROGM, much better than IDCAMS DELETE NVR.
Peter