I've been off IMS for too long, but it may be something in Recovery Control.
Len Rugen Metrics and Automation - [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Lizette Koehler Sent: Wednesday, January 18, 2017 9:14 AM To: [email protected] Subject: Re: IMS log files question See if DFHSM is running space management process on those volumes/pools. Or you can check on the IMS List and see if someone over there has had a similar issue To join, if you have not done so, use this URL IMS http://imslistserv.bmc.com/scripts/wa-BMC.exe?A0=ims-l Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Tony Thigpen > Sent: Wednesday, January 18, 2017 7:30 AM > To: [email protected] > Subject: Re: IMS log files question > > Which makes since. It is using the > "larger of [JCL vs SMS]" & <= RET_LIMIT. > > So, I am back to my original problem. I need to identify the process > that is suppose to be deleting the expired files from the VTOC? > > Tony Thigpen > > Burrell, Todd wrote on 01/18/2017 09:09 AM: > > Looks like your RETPD=45 is overriding the SMS parameters. > > > > -----Original Message----- > > From: IBM Mainframe Discussion List > > [mailto:[email protected]] On Behalf Of Tony Thigpen > > Sent: Wednesday, January 18, 2017 8:52 AM > > To: [email protected] > > Subject: Re: IMS log files question > > > > From the job logs where the file is created: > > > > //DFSSLOGP DD DSN=IMSVS.SLDSP.%SSID.D%ARDATE.T%ARTIME.V%ARVERS, > > // DISP=(NEW,CATLG,DELETE),RETPD=45, > > // UNIT=3390,VOL=SER=SIMS00,SPACE=(CYL,(1,1)) > > > > IGD101I SMS ALLOCATED TO DDNAME (DFSSLOGP) > > DSN (IMSVS.SLDSP.DBCT.D17018.T0040131.VF3 ) > > STORCLAS (SCIMSLOG) MGMTCLAS (MCIMSLOG) DATACLAS ( ) > > VOL SER NOS= HIMSL2 > > > > From the management class panel: > > MGMTCLAS EXPIRE EXPIRE RET PARTIAL PRIMARY > > NAME NON-USAGE DATE/DAYS LIMIT RELEASE DAYS > > --(2)--- ---(3)--- ---(4)---- --(5)-- ----(6)---- ---(7)-- > > MCIMSLOG 7 7 NOLIMIT NO 0 > > > > SMS is something I am just learning, but, if I am reading the manual > > right, > I would expect the files to be gone after 7 days. > > > > But, from the VTOC: > > Created Expires > > 2017.018 2017.063 > > > > It appears that I am missing something. Because here is the vtoc > > dates for > one of the old files: > > Created Expires > > 2015.190 2015.235 > > > > Tony Thigpen > > > > Peter Hunkeler wrote on 01/18/2017 01:55 AM: > >> > >>> I am reviewing the system VTOCs and I see a lot of IMS log files > >>> that contain a date/timestamp in their names. I know they are > >>> created by the IMS system using the skeleton proc member ARCHJCL. > >>> What I am seeing is that the file was created with a retention > >>> period of > 45 days. > >>> > >>> //DFSSLOGP DD DSN=IMSVS.SLDSP.%SSID.D%ARDATE.T%ARTIME.V%ARVERS, > >>> // DISP=(NEW,CATLG,DELETE),RETPD=45, > >>> // UNIT=3390,VOL=SER=SIMS00,SPACE=(CYL,(1,1)) > >>> > >>> But, I have daily files going back almost 2 years. > >> > >> > >> > >> > >> Is the RETPD honoured at allocation time? Look for message > >> IGD17364I in the > IMS joblog. What value is set for "RET LIMIT" in the management class. > If it is 0, then EXPDT and RETPD will be ignored, and EXPIRE NON-USAGE > and EXPIRE DATE/DAYS determine when space managment considers to > delete the data set. Any of those could be NOLIMIT. Or the value is larger > than your "almost 2 years". > >> > >> > >> Have you looked a the "Expiration date" in ISPF for any of those > >> data data > sets? > >> > >> > >> -- > >> Peter Hunkeler > >> > >> > >> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
