Re: IMS log files question
So long as you do not need them for IMS Backout or other stuff. The ISMF Panel for MGMTCLASS has a DISPLAY option or when you have a list Up, enter DISPLAY next to the entry. As for Cleanup. SMS and HSM are funny. they will only delete datasets when their algorithm is met. If your volumes are always light, it may not delete anything for a really long time. Lizette -Original Message- >From: Tony Thigpen <t...@vse2pdf.com> >Sent: Jan 18, 2017 3:30 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: IMS log files question > >I am thinking that my best option would be to run the following, then >figure out the storage group settings afterwards. > >//DELDSN EXEC PGM=ADRDSSU >//OUTVOL DD DUMMY >//SYSPRINT DD SYSOUT=* >//SYSINDD * > DUMP DATASET( - >INCLUDE(- >IMSVS.RLDSP.DBCP.**- >IMSVS.SLDSP.DBCP.**- >IMSVS.RLDSP.DBCT.**- >IMSVS.SLDSP.DBCT.**- > ) - >BY(EXPDT,LT,*) > ) - >OUTDD(OUTVOL) - >DELETE >/* > > >Tony Thigpen > >Tony Thigpen wrote on 01/18/2017 05:26 PM: >> At this point, I am trying to familiarize myself with the DFHSM and the >> contents of the manuals. With guidance from the list pointing me to the >> next step, I am learning a lot. Calling IBM will just get me an answer >> with no understanding. >> >> Tony Thigpen >> >> Lizette Koehler wrote on 01/18/2017 04:17 PM: >>> Of course my favorite last answer would be to open a case with DFHSM >>> and have them help you through DFSMS and DFSMShsm. They will probably >>> be faster >>> >>> Lizette >>> >>> >>> -Original Message- >>>> From: Lizette Koehler <stars...@mindspring.com> >>>> Sent: Jan 18, 2017 2:03 PM >>>> To: IBM-MAIN@LISTSERV.UA.EDU >>>> Subject: Re: IMS log files question >>>> >>>> The HSM Started task has an ARCCMDxx member that details all the >>>> stuff it is to do. >>>> >>>> You can issue a F dfhsmstcnamehere,Q SETSYS and see what is >>>> currently running. >>>> >>>> You can browse the ARCCMDxx member and see what it is going to do. >>>> SETSYS PRIMARYSPMGMTSTART( ) - >>>>SECONDARYSPMGMTSTART( ) - >>>>AUTOBACKUPSTART( ) - >>>>AUTODUMPSTART( ) >>>> >>>> ADDVOL VOL001 UNIT(3390) MIGRATION(ML1 NOSDSP) THRESHOLD(1) >>>> >>>> ADDVOL VOL002 UNIT(3390) - >>>> PRIMARY(NOAUTOMIGRATION - >>>> AUTORECALL - >>>> AUTOBACKUP - >>>> MIGRATE(999) - >>>> BACKUPDEVICECATEGORY(TAPE)) - >>>> THRESHOLD(100 100) >>>> >>>> You can review the Management class in ISMF and see what the policies >>>> are for the dataset (you only provided a snippet of the details. >>>> >>>> Use the DISPLAY function in ISMF for easier read >>>> >>>> >>>> -Original Message- >>>>> From: Tony Thigpen <t...@vse2pdf.com> >>>>> Sent: Jan 18, 2017 12:00 PM >>>>> To: IBM-MAIN@LISTSERV.UA.EDU >>>>> Subject: Re: IMS log files question >>>>> >>>>> How do I determine if the volume is part of the HSM backup process? I >>>>> have looked at the HSM backup logs and these volumes are never >>>>> mentioned >>>>> although other volumes are backed up. >>>>> >>>>> Tony Thigpen >>>>> >>>>> Lizette Koehler wrote on 01/18/2017 10:13 AM: >>>>>> 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 >>>>>> >>>>>> IMShttp://imslistserv.bmc.com/scripts/wa-BMC.exe?A0=ims-l >>>>>> >>>>>> >>>>>> >>>>>> Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IMS log files question
I am thinking that my best option would be to run the following, then figure out the storage group settings afterwards. //DELDSN EXEC PGM=ADRDSSU //OUTVOL DD DUMMY //SYSPRINT DD SYSOUT=* //SYSINDD * DUMP DATASET( - INCLUDE(- IMSVS.RLDSP.DBCP.**- IMSVS.SLDSP.DBCP.**- IMSVS.RLDSP.DBCT.**- IMSVS.SLDSP.DBCT.**- ) - BY(EXPDT,LT,*) ) - OUTDD(OUTVOL) - DELETE /* Tony Thigpen Tony Thigpen wrote on 01/18/2017 05:26 PM: At this point, I am trying to familiarize myself with the DFHSM and the contents of the manuals. With guidance from the list pointing me to the next step, I am learning a lot. Calling IBM will just get me an answer with no understanding. Tony Thigpen Lizette Koehler wrote on 01/18/2017 04:17 PM: Of course my favorite last answer would be to open a case with DFHSM and have them help you through DFSMS and DFSMShsm. They will probably be faster Lizette -Original Message- From: Lizette Koehler <stars...@mindspring.com> Sent: Jan 18, 2017 2:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IMS log files question The HSM Started task has an ARCCMDxx member that details all the stuff it is to do. You can issue a F dfhsmstcnamehere,Q SETSYS and see what is currently running. You can browse the ARCCMDxx member and see what it is going to do. SETSYS PRIMARYSPMGMTSTART( ) - SECONDARYSPMGMTSTART( ) - AUTOBACKUPSTART( ) - AUTODUMPSTART( ) ADDVOL VOL001 UNIT(3390) MIGRATION(ML1 NOSDSP) THRESHOLD(1) ADDVOL VOL002 UNIT(3390) - PRIMARY(NOAUTOMIGRATION - AUTORECALL - AUTOBACKUP - MIGRATE(999) - BACKUPDEVICECATEGORY(TAPE)) - THRESHOLD(100 100) You can review the Management class in ISMF and see what the policies are for the dataset (you only provided a snippet of the details. Use the DISPLAY function in ISMF for easier read -Original Message- From: Tony Thigpen <t...@vse2pdf.com> Sent: Jan 18, 2017 12:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IMS log files question How do I determine if the volume is part of the HSM backup process? I have looked at the HSM backup logs and these volumes are never mentioned although other volumes are backed up. Tony Thigpen Lizette Koehler wrote on 01/18/2017 10:13 AM: 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 IMShttp://imslistserv.bmc.com/scripts/wa-BMC.exe?A0=ims-l Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IMS log files question
At this point, I am trying to familiarize myself with the DFHSM and the contents of the manuals. With guidance from the list pointing me to the next step, I am learning a lot. Calling IBM will just get me an answer with no understanding. Tony Thigpen Lizette Koehler wrote on 01/18/2017 04:17 PM: Of course my favorite last answer would be to open a case with DFHSM and have them help you through DFSMS and DFSMShsm. They will probably be faster Lizette -Original Message- From: Lizette Koehler <stars...@mindspring.com> Sent: Jan 18, 2017 2:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IMS log files question The HSM Started task has an ARCCMDxx member that details all the stuff it is to do. You can issue a F dfhsmstcnamehere,Q SETSYS and see what is currently running. You can browse the ARCCMDxx member and see what it is going to do. SETSYS PRIMARYSPMGMTSTART( ) - SECONDARYSPMGMTSTART( ) - AUTOBACKUPSTART( ) - AUTODUMPSTART( ) ADDVOL VOL001 UNIT(3390) MIGRATION(ML1 NOSDSP) THRESHOLD(1) ADDVOL VOL002 UNIT(3390) - PRIMARY(NOAUTOMIGRATION - AUTORECALL - AUTOBACKUP - MIGRATE(999) - BACKUPDEVICECATEGORY(TAPE)) - THRESHOLD(100 100) You can review the Management class in ISMF and see what the policies are for the dataset (you only provided a snippet of the details. Use the DISPLAY function in ISMF for easier read -Original Message- From: Tony Thigpen <t...@vse2pdf.com> Sent: Jan 18, 2017 12:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IMS log files question How do I determine if the volume is part of the HSM backup process? I have looked at the HSM backup logs and these volumes are never mentioned although other volumes are backed up. Tony Thigpen Lizette Koehler wrote on 01/18/2017 10:13 AM: 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IMS log files question
I just found where the storage group has set: AUTO MIGRATE = 'INTERVAL' Based on my reading, then the volumes will not be 'cleaned' until they exceed a usage limit. Right now, the 4 volumes are 12, 12, 50 and 24% free. I have not been able to find where I can use 'DISPLAY' in ISMF. When I look at the storage group screen, I see: Storage Group Name : SGIMSLOG To ALTER Storage Group, Specify: Description ==> SYSTEM DUMP DATASETS ==> Auto Migrate . . I (Y, N, I or P) Migrate Sys/Sys Group Name Auto Backup . . N (Y or N) Backup Sys/Sys Group Name Auto Dump . . . N (Y or N) Dump Sys/Sys Group Name Dump Class . . . (1 to 8 characters) Dump Class . . . Dump Class . . Dump Class . . . Dump Class . . Allocation/migration Threshold: High . . 10 (1-99) Low . . 9 (0-99) Guaranteed Backup Frequency . . . . . . NOLIMIT (1 to or NOLIMIT) ALTER SMS Storage Group Status . . . N (Y or N) Tony Thigpen Lizette Koehler wrote on 01/18/2017 04:03 PM: The HSM Started task has an ARCCMDxx member that details all the stuff it is to do. You can issue a F dfhsmstcnamehere,Q SETSYS and see what is currently running. You can browse the ARCCMDxx member and see what it is going to do. SETSYS PRIMARYSPMGMTSTART( ) - SECONDARYSPMGMTSTART( ) - AUTOBACKUPSTART( ) - AUTODUMPSTART( ) ADDVOL VOL001 UNIT(3390) MIGRATION(ML1 NOSDSP) THRESHOLD(1) ADDVOL VOL002 UNIT(3390) - PRIMARY(NOAUTOMIGRATION - AUTORECALL - AUTOBACKUP - MIGRATE(999) - BACKUPDEVICECATEGORY(TAPE)) - THRESHOLD(100 100) You can review the Management class in ISMF and see what the policies are for the dataset (you only provided a snippet of the details. Use the DISPLAY function in ISMF for easier read -Original Message- From: Tony Thigpen <t...@vse2pdf.com> Sent: Jan 18, 2017 12:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IMS log files question How do I determine if the volume is part of the HSM backup process? I have looked at the HSM backup logs and these volumes are never mentioned although other volumes are backed up. Tony Thigpen Lizette Koehler wrote on 01/18/2017 10:13 AM: 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IMS log files question
Of course my favorite last answer would be to open a case with DFHSM and have them help you through DFSMS and DFSMShsm. They will probably be faster Lizette -Original Message- >From: Lizette Koehler <stars...@mindspring.com> >Sent: Jan 18, 2017 2:03 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: IMS log files question > >The HSM Started task has an ARCCMDxx member that details all the stuff it is >to do. > >You can issue a F dfhsmstcnamehere,Q SETSYS and see what is currently >running. > >You can browse the ARCCMDxx member and see what it is going to do. >SETSYS PRIMARYSPMGMTSTART( ) - > SECONDARYSPMGMTSTART( ) - > AUTOBACKUPSTART( ) - > AUTODUMPSTART( ) > >ADDVOL VOL001 UNIT(3390) MIGRATION(ML1 NOSDSP) THRESHOLD(1) > >ADDVOL VOL002 UNIT(3390) - >PRIMARY(NOAUTOMIGRATION - >AUTORECALL - >AUTOBACKUP - >MIGRATE(999) - >BACKUPDEVICECATEGORY(TAPE)) - >THRESHOLD(100 100) > >You can review the Management class in ISMF and see what the policies are for >the dataset (you only provided a snippet of the details. > >Use the DISPLAY function in ISMF for easier read > > >-Original Message- >>From: Tony Thigpen <t...@vse2pdf.com> >>Sent: Jan 18, 2017 12:00 PM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: IMS log files question >> >>How do I determine if the volume is part of the HSM backup process? I >>have looked at the HSM backup logs and these volumes are never mentioned >>although other volumes are backed up. >> >>Tony Thigpen >> >>Lizette Koehler wrote on 01/18/2017 10:13 AM: >>> 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 >>> >>> > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IMS log files question
The HSM Started task has an ARCCMDxx member that details all the stuff it is to do. You can issue a F dfhsmstcnamehere,Q SETSYS and see what is currently running. You can browse the ARCCMDxx member and see what it is going to do. SETSYS PRIMARYSPMGMTSTART( ) - SECONDARYSPMGMTSTART( ) - AUTOBACKUPSTART( ) - AUTODUMPSTART( ) ADDVOL VOL001 UNIT(3390) MIGRATION(ML1 NOSDSP) THRESHOLD(1) ADDVOL VOL002 UNIT(3390) - PRIMARY(NOAUTOMIGRATION - AUTORECALL - AUTOBACKUP - MIGRATE(999) - BACKUPDEVICECATEGORY(TAPE)) - THRESHOLD(100 100) You can review the Management class in ISMF and see what the policies are for the dataset (you only provided a snippet of the details. Use the DISPLAY function in ISMF for easier read -Original Message- >From: Tony Thigpen <t...@vse2pdf.com> >Sent: Jan 18, 2017 12:00 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: IMS log files question > >How do I determine if the volume is part of the HSM backup process? I >have looked at the HSM backup logs and these volumes are never mentioned >although other volumes are backed up. > >Tony Thigpen > >Lizette Koehler wrote on 01/18/2017 10:13 AM: >> 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 >> >> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IMS log files question
How do I determine if the volume is part of the HSM backup process? I have looked at the HSM backup logs and these volumes are never mentioned although other volumes are backed up. Tony Thigpen Lizette Koehler wrote on 01/18/2017 10:13 AM: 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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Wednesday, January 18, 2017 7:30 AM To: IBM-MAIN@LISTSERV.UA.EDU 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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Wednesday, January 18, 2017 8:52 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 EXPIRERETPARTIAL PRIMARY NAME NON-USAGE DATE/DAYSLIMIT 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IMS log files question
I've been off IMS for too long, but it may be something in Recovery Control. Len Rugen Metrics and Automation - umdoitmetr...@missouri.edu -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Wednesday, January 18, 2017 9:14 AM To: IBM-MAIN@LISTSERV.UA.EDU 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:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Tony Thigpen > Sent: Wednesday, January 18, 2017 7:30 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen > > Sent: Wednesday, January 18, 2017 8:52 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > 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 EXPIRERETPARTIAL PRIMARY > > NAME NON-USAGE DATE/DAYSLIMIT 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IMS log files question
So for the SMS Mgt class, if NON USE, then expire in 7 days. If someone touches the file, it resets the clock to the next 7 days. Day 1 - 7No accesses, Day 8 expire If on Day 3 someone browses, does 3.4 Info request, now a new 7 day wait period is started. There could be anything setting the expire/retention fields. I would download DAF from CBTTAPE.ORG and run the SMF Records (14,15,17,18,42) and see what is touching the dataset. You need to find what is actually accessing the files. DAF is a good starting point. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tony Thigpen > Sent: Wednesday, January 18, 2017 6:52 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 EXPIRERETPARTIAL PRIMARY > NAME NON-USAGE DATE/DAYSLIMIT 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tony Thigpen > Sent: Wednesday, January 18, 2017 7:30 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Tony Thigpen > > Sent: Wednesday, January 18, 2017 8:52 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > 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 EXPIRERETPARTIAL PRIMARY > > NAME NON-USAGE DATE/DAYSLIMIT 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Wednesday, January 18, 2017 8:52 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 EXPIRERETPARTIAL PRIMARY NAME NON-USAGE DATE/DAYSLIMIT 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This email transmission and any accompanying attachments may contain CSX privileged and confidential information intended only for the use of the intended addressee. Any dissemination, distribution, copying or action taken in reliance on the contents of this email by anyone other than the intended recipient is strictly prohibited. If you have received this email in error please immediately delete it and notify sender at the above CSX email address. Sender and CSX accept no liability for any damage caused directly or indirectly by receipt of this email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IMS log files question
Looks like your RETPD=45 is overriding the SMS parameters. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Wednesday, January 18, 2017 8:52 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 EXPIRERETPARTIAL PRIMARY NAME NON-USAGE DATE/DAYSLIMIT 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This email transmission and any accompanying attachments may contain CSX privileged and confidential information intended only for the use of the intended addressee. Any dissemination, distribution, copying or action taken in reliance on the contents of this email by anyone other than the intended recipient is strictly prohibited. If you have received this email in error please immediately delete it and notify sender at the above CSX email address. Sender and CSX accept no liability for any damage caused directly or indirectly by receipt of this email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 EXPIRERETPARTIAL PRIMARY NAME NON-USAGE DATE/DAYSLIMIT 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: IMS log files question
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IMS log files question
IMS itself does not take any action automatically. Since the logs are as close to a complete audit trail for any user interaction with the IMS system, they might need special handling from a retention stand point. From a database recovery perspective, if the DBRC RECON data set for the IMS no longer has the log data set name recorded in it, it would probably be safe to delete. An IMS utility can execute a DELETE.LOG INACTIVE LIST command which should produce a list of log data sets still listed in the RECON data set that are no longer needed to recover a database, at which point a formal process to actually delete the unneeded log from that list could be run using your favored utility. On 1/17/2017 5:05 PM, Tony Thigpen wrote: > Can someone point me in the right direction? > > 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. > > My conclusion is that something stopped cleaning up the files "back > when". > > Is the clean-up of expired files something normally handled within IMS > or outside of IMS? > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IMS log files question
First question. Is this in an SMS managed pool? Or NON SMS Managed? Does DFHSM do anything with the dasd these datasets reside on. If the RETPD=45 is met, then there may be a batch DFDSS clean up job, or an SMS Management class It would be helpful to see if the dataset has a management class that specifies something other than 45 days. Some products will determine their own time to expire datasets. Lizette -Original Message- >From: Tony Thigpen <t...@vse2pdf.com> >Sent: Jan 17, 2017 5:05 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: IMS log files question > >Can someone point me in the right direction? > >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. > >My conclusion is that something stopped cleaning up the files "back when". > >Is the clean-up of expired files something normally handled within IMS >or outside of IMS? > > >-- >Tony Thigpen > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IMS log files question
Can someone point me in the right direction? 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. My conclusion is that something stopped cleaning up the files "back when". Is the clean-up of expired files something normally handled within IMS or outside of IMS? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
