What is the problem with a userid.NETRC with a UACC of NONE [and maybe an additional PE ID(*) ACC(NONE)]? Except for someone with OPERATIONS, everyone but the user should be locked out.
Charles Mills <[EMAIL PROTECTED]> wrote: I just posted the NETRC question but perhaps I should instead ask the fundamental underlying question. Here is what I want to do. I want to have a program ABC running in a "normal" batch job that might be submitted by any of a large number of TSO users invoke FTP and have it log on to a remote z/OS FTP server and, among other things, submit a job. I have complete control over the INPUT (command) file which is built on the fly. Here is the key question: I would like the FTP logon to be with the userid of the original user who submitted the batch job. Do any of you creative souls want to suggest a reasonable way to do this? A file with possible userids and the associated remote passwords fulfills the letter of the above specs but is obviously totally unacceptable from a security point of view. I don't think NETRC does the job because a "local" NETRC is a security disaster and a "global" NETRC file would only provide one userid and password for the remote machine -- my whole point is I want to "propagate" each individual user id. Please don't ask "why do you want to do it that way?" The answer is "I don't, the customer does." Charles Mills ---------------------------------------------------------------------- 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 --------------------------------- Yahoo! DSL Something to write home about. Just $16.99/mo. or less ---------------------------------------------------------------------- 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