Create the profile with initial program *NONE and intial menu *signoff. LMTPCB(*YES). As part of the setup you specify the home directory. The only issue then is excluding that profile from all production libraries and other folders. User would still need a password to connect and you would want to find some way of changing it and communicating to the remote user on a regular basis. =============================================================== The above is a reasonable start. It doesn't cover how to keep the profile out of everything except FTP nor how to restrict that profile to a particular FTP directory. The profile would be restricted from telnet access because of the combination of INLMNU(*SIGNOFF) and LMTCPB(*YES). However, remote database access, remote command/distributed program call, REXEC, and most other accesses would still be available. It needs to be understood that a profile is still a profile. If various servers are going to be configured to reject access to that profile, then exit programming is the way to go. The problem quickly arises that different servers may have different exit program interfaces. You can't just write a single program. You need to write one for every interface format. Fortunately, you can write the exit program in two parts -- one part accepts parameters from whichever server it's attached to and the other part takes a user name and tests if it should be rejected or not. But that quickly runs into the next problem. Almost all of the servers have multiple functions. Exit programs can be called for each kind of function that is requested by a client, and each type of request can be accepted or rejected. Again fortunately, most servers have an initiate or 'connect' function which is the only one you'd be interested in. In short, if the requested function is 'Connect' and the user is USERX, then return a 'Reject' indication; otherwise return 'Accept'. Essentially all other functions can simply return a default 'Accept'. USERX will never get that far. But all of that is probably more than you want to get into. What you probably should review is <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzaiq/rzaiqftpanon.htm">Configuring anonymous File Transfer Protocol</a> and <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzaiq/rzaiqextprog.htm">Writing exit programs for anonymous File Transfer Protocol</a> -- example programs are shown in related sections. With anonymous FTP, you won't need to communicate a user profile to anyone, you can control the directory and you won't need to consider any of the other servers. You might get away from this fairly easily. Tom

Create the profile with initial program *NONE and intial menu *signoff. LMTPCB(*YES). As part of the setup you specify the home directory. The only issue then is excluding that profile from all production libraries and other folders. User would still need a password to connect and you would want to find some way of changing it and communicating to the remote user on a regular basis. =============================================================== The above is a reasonable start. It doesn't cover how to keep the profile out of everything except FTP nor how to restrict that profile to a particular FTP directory. The profile would be restricted from telnet access because of the combination of INLMNU(*SIGNOFF) and LMTCPB(*YES). However, remote database access, remote command/distributed program call, REXEC, and most other accesses would still be available. It needs to be understood that a profile is still a profile. If various servers are going to be configured to reject access to that profile, then exit programming is the way to go. The problem quickly arises that different servers may have different exit program interfaces. You can't just write a single program. You need to write one for every interface format. Fortunately, you can write the exit program in two parts -- one part accepts parameters from whichever server it's attached to and the other part takes a user name and tests if it should be rejected or not. But that quickly runs into the next problem. Almost all of the servers have multiple functions. Exit programs can be called for each kind of function that is requested by a client, and each type of request can be accepted or rejected. Again fortunately, most servers have an initiate or 'connect' function which is the only one you'd be interested in. In short, if the requested function is 'Connect' and the user is USERX, then return a 'Reject' indication; otherwise return 'Accept'. Essentially all other functions can simply return a default 'Accept'. USERX will never get that far. But all of that is probably more than you want to get into. What you probably should review is <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzaiq/rzaiqftpanon.htm">Configuring anonymous File Transfer Protocol</a> and <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzaiq/rzaiqextprog.htm">Writing exit programs for anonymous File Transfer Protocol</a> -- example programs are shown in related sections. With anonymous FTP, you won't need to communicate a user profile to anyone, you can control the directory and you won't need to consider any of the other servers. You might get away from this fairly easily. Tom