I know you can't, but tell them all that their NIMBY problem needs a rational solution, not a FYUSTM (Obscene comment abbreviated) impossible solution. Shove the output of the FTP step into a dataset, rexx or what ever to evaluate, ship email if needed. PUT THE damn thing in a cataloged procedure and be done with it.
> -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John > Sent: Friday, March 03, 2006 11:13 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: Unusual FTP request. > > > -----Original Message----- > > From: IBM Mainframe Discussion List > > [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Trojak > > Sent: Friday, March 03, 2006 12:53 PM > > To: IBM-MAIN@BAMA.UA.EDU > > Subject: Re: Unusual FTP request. > > > > > > How about a conditional step after the FTP that checks > return code GT > > zero. We do that and send an e-mail via SMTP to the Production team > > along with any "special" instructions. > > Dennis.. > > Possible, but unlikely. The programmers are really wanting > something so that they are not "in the loop" at all about > ftp. That is, they don't want the responsibility to put the > FTP step in the job, to check the RC and send mail, or > anything else. They want the "ftp team" to set up all of > that, including any userid/password requirements, maintaining > the IP address of the server, maintaining the ftp statements, > etc. From what I get, they want to say something like: "I'm > going to create dataset XYZ. > It needs to be ftp'ed to server ABC, into subdirectory DEF, > and given the name GHI. You figure out what needs to be done > to get the ftp to work and set it up independantly of my > job." Then, when XYZ is created, the ftp automagically occurs > without anything in their JCL. Similar to a dataset trigger > in CA-7. I.e. they really want out of the business of data > transfer beyond the initial "put this dataset on that server > and give it this name in this subdirectory". Should anything > change after that (e.g. the dataset should go to another > server, the server file name or subdirectory should change), > they don't even want to know about it. > That would be the responsibility of the "ftp team" to update > the ftp process (whatever it turns out to be). > > NFS/SMB has been mentioned in another post. I have done an > NFS import of a UNIX subdirectory onto the z/OS system. It > works quite well. However, the same problem occurs. If the > job terminates trying to copy to the NFS/SMB share, the > programmer would get called and they don't want to be. They > would still want "someone else" to do the NFS/SMB copy > function and be responsible for any problems with it. So, ftp > or NFS/SMB it is basically all the same to them. They don't > want anything related to the copying in any process for which > they are responsible. And they really don't want to set up a > second job to do the ftp/NFS work either. > > I know that sounds like they are being lazy, but they have > had such problems with this - again due mainly to server > problems - that they are frustrated and just want OUT! It is > one thing to get called about a problem you can fix. It is > another thing to get calls for a problem that is outside your > ability to fix or even diagnose properly. > > Well - off to the annual company meeting. Such fun. > > -- > John McKown > Senior Systems Programmer > UICI Insurance Center > Information Technology > ---------------------------------------------------------------------- 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
