Denis I think Radoslaw's point 2 is what you should check.
SYS1.TCPPARMS is one of the options for accessing a "resolver configuration file" and SYS1.TCPIP.HOSTS.SITEINFO is one of the options for accessing "local host tables". These files are normally accessed by an application by way of the "resolver" address space. I don't believe this standard mode of access requires RACF authorisation. If it did, access to the "resolver" functions would be rather troublesome, leading to just the sort of data set access problems you describe. If indeed, use of the "resolver" functions does require "read" access to the "resolver configuration file" and, assuming your choice for resolving domain names to IP addresses and IP addresses to domain names relies on them, to "local host tables", then your RACF folk are going to have to permit "read" access somehow. Very strictly, a Sockets program using "resolver" functions will need "read" access to a "resolver configuration file" and the relevant "resolver" calls will need "read" access to "local host tables". What experience do others have regarding RACF and access to files relating to using the "resolver" function in Socket programs written in COBOL or otherwise? It's worth knowing these days that "resolver" functions are handled by a separate address space, the RESOLVER address space. Just to be sure, you should check what access the application program is making to these data sets. If there is no obvious access to specifically these data sets, it may be a "bug" of some sort in the COBOL Sockets support, specifically for "resolver" calls such as GETHOSTBYNAME. If, on the other hand, the application programmers really are trying to access these data sets without using the "resolver" calls, then there may well be a flaw in their design. If there is no flaw in their design - or - access to "resolver" functions really does need the "read" access I mentioned above, you will need to pursue the RACF access techniques which - I think (I'm a RACF novice and intend to stay that way) - the other posters are suggesting. Actually, if all Sockets programs require "read" access to "resolver"-related files - and - if your PERMIT statement means what I think it may mean, you should generalise your solution, perhaps by adopting a solution like that proposed by Rob Scott so that you establish a class for all Sockets applications - which will almost certainly always need access to "resolver"-related files. You should also ensure that you provide such a PERMIT statement for *all* "resolver"-related files. Thus, for example you will also need to cover SYS1.TCPIP.HOSTS.ADDRINFO and, assuming your "high-level-qualifier" is "SYS1.TCPIP", SYS1.TCPIP.ETC.PROTO, SYS1.TCPIP.ETC.SERVICES and SYS1.TCPIP.STANDARD.TCPXLBIN. You may need the assistance of whomever in your installation understands your use of the "resolver" functions to be sure you cover all relevant files. Chris Mason ----- Original Message ----- From: "Denis Gäbler" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Wednesday, 22 November, 2006 2:15 PM Subject: TCPIP Racf Protection for application? > Hi, > > there is a COBOL application which is supposed to do TCP/IP calls nowadays. When starting the application (TCPIPAPP) it requests READ access to the following datasets: > SYS1.TCPIP.HOSTS.SITEINFO > SYS1.TCPPARMS > The application is started with the callers Userid. > > RACF people don't like to grant generic READ permission to all users. Is there any other solution? > Could something like that be used to only allow that specific program access to TCP/IP? > PERMIT 'SYS1.TCPPARMS' CLASS(DATASET) ID(*) ACCESS(READ) WHEN(PROGRAM(TCPIPAPP)) > > Are there better solutions, ideas for that? > > Thanks, Denis. ---------------------------------------------------------------------- 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
