Let's say you have 10 files that are FTPed. How would you identify the destination of the 10 files? Let's further assume that a month later a new FTP file is created. How would you determine the destination of the new file?
Selvius Turner -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Friday, March 03, 2006 6:52 AM To: [email protected] Subject: Unusual FTP request. One of our applications people came up with a, uh, unusual request today. We use ftp to transfer data from the z/OS system to various, internal, ftp servers. Currently, this is done by adding an ftp step to the end of the job which creates the data set to transfer. This usually works. However, there have been cases where the ftp step ends with a bad return code due to various problems on the remote (server) side. Some examples would be: (1) the userid on the ftp server has been deleted/revoked; (2) the subdirectory on the server has been removed or has the wrong attributes (i.e. the ftp userid cannot create a file in that subdirectory); (3) the file to be transferred in to already exists on the server, but is owned by another userid and so cannot be replaced; (5) the IP address of the server has changed (very rare!). What the programmer would like would be for the production job to simply create the dataset which is to be ftp'ed. All datasets which are to be ftp'ed are created with a specific, unique, high level qualifier. Whenever a dataset with this high level qualifier is created, "something" triggers a process (job, started task, other) which is passed the name of the dataset just created. This process then does some sort of "look up" on the name of the dataset just created and generates the appropriate ftp commands, which are "somehow" passed to an "ftp processor". If the "ftp processor" has a problem, then the "ftp team" would be alerted that an ftp failed. The "ftp team" would be able to look at the ftp output and hopefully determine what failed, why, and then fix it. This would releave the normal programmers from being called. These people: (1) don't have the authority on the ftp server to see what the problem might be, if the problem is there; (2) don't know how to determine if the problem is on the server or the z/OS side; (3) don't want to be responsible for ftp processing at all. Has anybody heard of any "process" which could do such a thing? There are two restrictions: (1) No money is budgetted for this; and (2) Tech Services doesn't want to be responsible for writing any code because we just don't have the time to support yet another "application". There are only 3 of us to support z/OS, CICS, and all the vendor products. We are not developers (although two of us are fairly good HLASM programmers and have done development before). -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
