MVSFORUMS.com

ed.sam13 · Beginner Joined: 09 Aug 2010 Posts: 31 Topics: 11

I have an upstream system which pushes files on SFT and it comes to us on the mainframe as GDG versions. The requirement is to process all the files without missing any generation and also in the same sequence as the files came in. I was thinking about always reading G0001 generation, and once processed delete this generation. But there is a possibility that while i am processing the G0001 generation, another file comes in as G0002.

So in order to handle this scenario, at the end of the job i want to renumber all the GDG generations from 1.

For example, if I am processing G0001 and i get 3 GDG generations G0002, G0003 and G0004, at the end of the processing i want to re-number all of then to G0001, G0002 and G0003 so that i consistently read from G0001.

Is there a way to acheieve this?

kolusu · Posted: Wed May 27, 2015 2:50 pm Post subject:

ed.sam13,

Why bother hard coding the names of the GDG generations? Let your upstream send in all the files thru out the day and at the end of the day, read all the generations with just base name and copy contents into a single back up file (LIFO order) and then delete all the generations. With z/OS 2.1 you can copy the GDG generations in FIFO order too.

Alternatively if you don't have the z/OS 2.1 system , then check the Smart DFSORT trick "Copy GDG records in first in, first out order" here

http://www-01.ibm.com/support/docview.wss?uid=isg3T7000094
_________________
Kolusu
www.linkedin.com/in/kolusu

ed.sam13 · Beginner Joined: 09 Aug 2010 Posts: 31 Topics: 11

hi Kolusu, Thanks for your reply. We have z/OS 1.13. Also I am supposed to validate the header and the trailer for each file and send out a error file for each file.

kolusu · Posted: Thu May 28, 2015 10:40 am Post subject:

ed.sam13 · Beginner Joined: 09 Aug 2010 Posts: 31 Topics: 11

hi Kolusu,
Thanks for your reply. We have Syncsort 2.1 in our shop. But anyway I will try that DFSORT trick.

To answer your questions.
1) The LRECL is 3000 bytes and the RECFM is FB
2) The Header or trailer record is identified by byte 1 of the record. It is H for header and T for trailer.
3) We get the date, sequence number of the file and hash keys which we validate against the database. The trailer has the record count which should tally against the number of detail records.
4) I dont need to copy at all. But I need to process the file and update database as soon as i receive them.

The file looks something like this

kolusu · Posted: Fri May 29, 2015 10:18 am Post subject:

ed.sam13 · Beginner Joined: 09 Aug 2010 Posts: 31 Topics: 11

Thanks for your reply. Not sure if I follow you 100%.

The problem is that SFT is setup to create a new GDG generation whenever a new file comes in. Changing the SFT setup to write to a flat file is out of scope. The job will always process the last generation of the GDG. The file processing job can run for 45 mins to 1 hour, within which there is a chance that 2 new generations kick in. The job when it completes its current iteration when it restarts to process, it will skip 1 generation.

kolusu · Posted: Fri May 29, 2015 3:45 pm Post subject: