While we are IPLing the test lpar for the first time after the fresh installation, we are geeting the following errors,
IOEZ00055I zFS kernel: initialization complete.
IKJ56225I DATA SET OMVS.ROOT ALREADY IN USE, TRY LATER+
IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER
IOEZ00003E While opening minor device 10000, could not open dataset
OMVS.ROOT.
BPXF029E ROOT FILE SYSTEM OMVS.ROOT 616
WAS NOT MOUNTED. RETURN CODE = 00000072, REASON CODE = EF096058
Here, we are using zFS file system.
The dataset OMVS.ROOT is using by OMVS address space.
But in our some other test Lpar, the same is used by zFS address space.
Have any one came accross problem like this? If so, please share your solution.
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
BPXF029EROOT FILE SYSTEM name WAS NOT MOUNTED. RETURN CODE = return_code, REASON CODE = reason_code
Explanation:
During z/OS UNIX initialization or in response to the SET OMVS=(xx) command, the system could not mount the specified file system.
In the message text:
name
The file system name specified on a ROOT statement in the BPXPRMxx parmlib member is either the name of the file system (FILESYSTEM parameter), or the name of the DD statement (DDNAME parameter) used to allocate it. For the HFS file system, FILESYSTEM refers to the name of the HFS data set containing the file system.
return_code
The return code from the mount request.
reason_code
The reason code from the mount request. For an explanation of the return code and reason code, see z/OS UNIX System Services Messages and Codes.
System action:
The file system is not mounted. The system is activated without a ROOT.
For a shared file system configuration, if the ROOT FILE SYSTEM was already mounted and owned by another system, OMVS will fail to initialize and will SHUTDOWN.
Operator response:
Contact the system programmer.
System programmer response:
Do one of the following:
•Ask the operator to correct the problem in BPXPRMxx. IPL the system to start z/OS UNIX with the revised member.
•Ask a superuser to enter the corrected information using the TSO/E MOUNT command. In this case specify '/' as the mountpoint.
Consult the documentation for the file system type specified with the TYPE parameter on the ROOT statement in the BPXPRMxx member specified to z/OS UNIX. Make changes as appropriate.
If this is a shared file system configuration and the ROOT file system is already mounted, this mount failure may be a temporary condition. If the reported RETURN CODE is EMVSERR (x"9D") and the REASON CODE is JRTgtMemberInactive (X"xxxx03CC") then the server for the ROOT file system has failed and a new server is being established. Issue the F OMVS,RESTART system command to restart OMVS.
* there is no problem in BPXPRM00 and BPXPRMFS members in parmlib.
* while we are trying to mount using TSO/E, we are getting same error "BPXF029E"
And the system is activated with default root "SYSROOT"
And as I mentioned before, all OMVS datasets are used by OMVS address space. But in our another lpar, all omvs datasets are using by zFS address space.
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
Quote:
The dataset OMVS.ROOT is using by OMVS address space.
But in our some other test Lpar, the same is used by zFS address space.
This is true -- and completely unrelated to your problem. Our OMVS-mounted directories show they are in use by zFS, even though they are mounted to OMVS and usable. So you may think this is an issue for your site -- but it is not.
Quote:
* there is no problem in BPXPRM00 and BPXPRMFS members in parmlib.
If this were completely true, you would not be posting anything here because you would not have an issue. We don't use shared file systems, but in looking over the material in the Unix System Services Planning manual, there are a lot of potential problems to watch out for. You need to review all console messages -- there should be a clue somewhere about the problem (coupling facility messages could indicate your SYSPLEX(YES) failed in BPXPRM00 for example).
