Mark, >From his note I believe it is done to prevent wrong data being offloaded via >automated batch process to feed other ETL processes outside that LPAR. If that is not the case, I am curious why IND$FILE is allowed and not FTP.
Natarajan >>> Mark Zelden <[email protected]> 7/8/2009 9:41 AM >>> On Wed, 8 Jul 2009 11:10:00 -0500, Todd Last <[email protected]> wrote: >Regarding the FTP alias... We have another lpar which is a clone of the >production lpar. We do not want users (or automated batch jobs!!) to >accidentally FTP in or out of the lpar. On the cloned system, we code >dummy modules in front of SYS1.TCPIP.SEZALOAD to prevent the FTP. >However, us system programmers, want a back door (thus, we created >Z062016 - weird name? - think hex). Users can get files in and out of this lpar >by doing a IND$FILE. > Thanks for the explanation. I guess that makes sense, but I would rather protect with RACF since someone could find out the secret name. You really aren't securing anything. But that discussion is for another thread. :-) Another thought... i I you have dummy modules ahead of sezaload outside of SMP/E to prevent usage, why not just copy FTP as Z062016 the same way? Since it is only a "back door" anyway, I wouldn't be all that concerned with missing service when you apply normal maintenance. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[email protected] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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 NOTICE OF CONFIDENTIALITY The information contained in this communication, including but not limited to any accompanying document(s) and/or attachment(s), is privileged and confidential and is intended solely for the above-named individual(s). If you are not the intended recipient, please be advised that any distribution, copying, disclosure, and/or use of the information contained herein is strictly prohibited. If you received this communication in error, please destroy all copies of the communication, whether in electronic or hard copy format, and immediately contact the Security Office at EDFUND at (916) 526-7539 or [email protected]. Thank you. ---------------------------------------------------------------------- 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
