I guess RACF is not installed on the system: TCPIP normally has a LINK to TCPMAINT 198, otherwise it wouldn't start, so this most probably is a LINK in the CP directory. So, yes, as Rob suggested: specify the password on OBEYFILE.
I normally place only the new statements in an "xxxx TCPIP" on my own 191 A-disk, issue OBEYFILE xxxx and if all goes well, I insert the new statements in PROFILE TCPIP on TCPMAINT 198. By using a file with only the changed statements, it is easier to know if TCPIP agrees or not. OBEYFILE for the whole PROFILE always gives error messages. Note "changed statements" means a whole section from PROFILE TCPIP, e.g. from ASSORTEDPARMS to ENDASSORTEDPARMS Because most of the time TCPIP resets a whole section when loading new definitions for it. -- Kris Buelens, IBM Belgium, VM customer support 2007/6/29, Rob van der Heij <[EMAIL PROTECTED]>:
On 6/29/07, Miguel Villar <[EMAIL PROTECTED]> wrote: > obeyfile profile tcpip d1 > > VM TCP/IP Obeyfile > Requesting TCPIP to accept 'PROFILE TCPIP *' on TCPMAINT 0198 ... > TCPIP says: Minidisk not available > Ready(00008); T=0.01/0.01 10:39:28 > Have a look at the console log of the TCPIP virtual machine. It probably will tell you the TCPMAINT 198 has a read password that should be specified on the OBEYFILE command to allow access. When you have RACF it needs a permit to be able to link to the disk. But... I am not sure you can in general make it work like this. Many of the sections in the TCPIP PROFILE can not be repeated like that (but it may be that you only get error messages for which cannot be done). The way I normally do this is * create the new PROFILE TCPIP on the TCPMAINT A-disk. * Compose a new file which has the differences in the way it would work with OBEYFILE (also on TCPMAINT A-disk) and issue OBEYFILE against that (with the read password of the disk) * When I can still get to the system (so I did not break the stack) I put the new PROFILE TCPIP on the TCPMAINT 198 and let TCPIP pick it up there at next restart. The good thing about this is that a FORCE / XAUTOLOG of TCPIP will get it to what it was before you started the changes. The bad thing is that you need to manually verify you extracted the right things as being changed. Alternative is to recycle VM TCP/IP to activate changes (with all nasty implications). Rob
