Sending files every 15 minutes.

[Nischitha Ganesh]

Hi,

For a requirement we're need to send FTP 5 files to a server. But these need to be sent across every 15 minutes. What is the best way to implement this '15 minutes event', please advise.

[Akatsukami]

Have your scheduler release the job every 15 minutes.

[Nischitha Ganesh]

But will not that be a too much work for scheduler? I mean that's the only solution actually but that would mean 4 instances of one file in one hour and in 24 hours it would 24*4=96 files for a day for one file. 480 total files for 5 such files. That sounded like too much work. If instead of sending files there can be some other way round? That's what I'm after but I think it's a design question rather than a technical question to be answered here.

[Robert Sample]

Why do you think it is too much work for the scheduler? The scheduler is NOT transferring 5 data sets every 15 minutes, it is submitting a job you write every 15 minutes to FTP the data sets and that is the kind of thing schedulers are designed to do.

I mean that's the only solution actually

I don't know why you think this is the only solution -- I can think of two others just off the top of my head:
1. Write a CICS transaction that is interval started every 15 minutes that submits a job to JES (either through TD queue or SPOOL commands) to do the FTP.
2. Use the server scheduler (cron in Unix or Windows Scheduler -- or whatever Microsoft calls it now -- in Windows) to pull the data sets from the mainframe every 15 minutes.

And why look for some other way to do it? FTP is a good, solid solution for what you want to do. Most other solutions either depend upon your site having (or buying, at a potential cost of many thousands of dollars) the appropriate software, or will require a lot of work.

[nicc]

The scheduler is a program so how is it "too much"? It might be too much work for you to provide the scheduling group with the required information and if that is the case then you should find a job that does not require you to do too much work. Remember, all your scheduling group has to do is enter the criteria for ech job once and it is there until the end of time - or it is deleted as not required.

[Nischitha Ganesh]

Why do you think it is too much work for the scheduler? The scheduler is NOT transferring 5 data sets every 15 minutes, it is submitting a job you write every 15 minutes to FTP the data sets and that is the kind of thing schedulers are designed to do.

I mean that's the only solution actually

I don't know why you think this is the only solution -- I can think of two others just off the top of my head:
1. Write a CICS transaction that is interval started every 15 minutes that submits a job to JES (either through TD queue or SPOOL commands) to do the FTP.
2. Use the server scheduler (cron in Unix or Windows Scheduler -- or whatever Microsoft calls it now -- in Windows) to pull the data sets from the mainframe every 15 minutes.

And why look for some other way to do it? FTP is a good, solid solution for what you want to do. Most other solutions either depend upon your site having (or buying, at a potential cost of many thousands of dollars) the appropriate software, or will require a lot of work.

Thanks. I was thinking about maintaining such a system. Like if there is a problem

1. In data which was sent across and we need to verify the sent data, we'd be dealing with 480 files in a day. Then it will become very tough job to tell from where the file started showing corrupt data.

2. If there is an abend in between, the 15 minute frequency will put too much burden on us as the sender and resolver of the problem.

[Nischitha Ganesh]

The scheduler is a program so how is it "too much"? It might be too much work for you to provide the scheduling group with the required information and if that is the case then you should find a job that does not require you to do too much work. Remember, all your scheduling group has to do is enter the criteria for ech job once and it is there until the end of time - or it is deleted as not required.

I think my question is more to do with design than a technical problem, which is why perhaps you say so.

[Robert Sample]

1. In data which was sent across and we need to verify the sent data, we'd be dealing with 480 files in a day. Then it will become very tough job to tell from where the file started showing corrupt data.

2. If there is an abend in between, the 15 minute frequency will put too much burden on us as the sender and resolver of the problem.

These are both design issues. For #1, If the data is being processed immediately upon receipt, write a log showing the results of each file processed with new entries being posted to the end of the log. If you start having corruption issues, you scan the log (manually or by writing a program) to find the last good file and proceed from there. For #2, the CICS option might be the way to go -- you could then have the CICS program read a VSAM data set record with a PROCEED / HALT flag in it. If the flag is set to PROCEED (which would be the default), the files are FTPed every 15 minutes. If the flag is set to HALT (which could be done by a transaction-driver program or by directly updating the record with CECI), the files are NOT FTPed. Two fairly small programs, one VSAM data set -- maybe a day or two of effort (depending upon how good the CICS programmer is -- I could probably finish and test the whole thing in a day if I had to).

One of my previous employers was a newspaper and we used a similar CICS system to send missed delivery notifications to the carriers -- except the CICS transaction ran every 5 minutes from 6 AM to noon. If you want more details, contact me by PM as there are some considerations required that I haven't mentioned here.

[Nischitha Ganesh]

Thanks Robert. I have sent a PM to you.