If you have the FDR reporting tools, you could select, sort, and then generate the JCL to accomplish this.
--- z...@cdc.gov wrote: From: "Burrell, C. Todd (CDC/OCOO/OCIO/ITSO) (CTR)" <z...@cdc.gov> To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fastest way to read OLDEST GDG entry Date: Tue, 17 Nov 2015 14:17:04 +0000 It seems you could do a quick LISTCAT in step one of a job, then in step 2 parse out the LISTCAT for the GDG via REXX and sort the GDG's in descending order and generate the JCL to process the data and submit? It's a little work, but it should be fairly easy to implement. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, November 17, 2015 9:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fastest way to read OLDEST GDG entry So for this process, the files need to be read in FIFO order of creation. The use of the GDG rather than a HLQ.XXX.Dxxxxx.Txxxx naming convention was to make it easier to process the files. So GDGs are typically in LIFO order, for this process the first one created needs to be process first and then read and processed to the current version. I believe date/time read of a seq file has always been a challenge on the mainframe as the naming convention does not allow for a more granular read of many files into input. So I have the following conditions File1 created on date and time File2 created on date and time+15 mins File3 created on date and time+60 mins Then I need to read File1 first, process it, delete it Next file2, process it and delete it Next File3, process it and delete it All the time new files are coming in. If I delete the GDG base I may delete data that is not processed. The file cannot be mod'd due to the face it is a TSO XMIT'd file. I need to RECEIVE the GDG (oldest version) process it and then delete what I have just processed. I have heard the GDG limit in z/OS V2.2 will be higher, so it may not be much of an issue for limit values. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Greg Shirey > Sent: Tuesday, November 17, 2015 6:50 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Fastest way to read OLDEST GDG entry > > Why does the process need to delete the oldest GDG after it reads it? Won't the > oldest one be deleted when the next +1 GDG is created? > > Regards, > Greg Shirey > Ben E. Keith Company > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Lizette Koehler > Sent: Tuesday, November 17, 2015 4:06 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Fastest way to read OLDEST GDG entry > > I have a request to read the oldest GDG to process. But CSI is slow > sometimes and > better other times. > > So here is the basic request > File lands as a GDG often > > The process needs to read the oldest GDG and then delete it. > > GDGs must be read in correct order for time/date processing > > I tried GDGORDER on the JCL for z/OS V2.1 and it works great on the > Base. But using > //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to work. > > Is there another process that could be used to identify the OLDEST GDG > for Input and > then delete that GDG? Or is there another way to handle this > situation? I was going > to see if the LISTC could be faster than CSI. > > The process should be native to z/OS and not a vendor product. Or > shareware/freeware is okay. ---------------------------------------------------------------------- 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 _____________________________________________________________ Netscape. Just the Net You Need. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
