A PDS without members can still be opened so that appears to be a secondary problem. Is there only one copy of each dataset on the target system? Are they on the IPL volume? Are they catalogued correctly? Did the DUMP and RESTORE jobs use the ADMINISTRATOR operand to bypass security checking? Do the source and target volumes have the same geometry (we got burned dumping a 9345 and restoring to a 3390)? Is the target volume at least as large as the source? Did you IPL with the correct LOADxx member? Are the PARMLIB statements in it correct?
-----Original Message----- From: Sebastian Welton [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 8:36 AM To: IBM-MAIN@BAMA.UA.EDU Subject: DFSMS Full Volume Restore Oddity I have come across a rather strange problem in moving data between 2 systems. Using DFSMS DUMP FULL on an OS/390 2.10 system to dump a full volume to a file and then moving it over to zOS 1.4 and using RESTORE FULL to restore it to a new disk it seems that not all datasets are being restored. All jobs complete with CC=0 but when we IPL`ed an error cam eup stating that it could not open either SS1.PARMLIB or SYS1.IBM.PARMLIB. Upon further investigation it was found that these datasets after the restore were empty whereas on the originating system they have (important) members in. We populated the datasets with the members but now get an error to do with an LPA library that cannot beloaded but they all seem full. We believe that not all libraries are full and that somewhere along the line the restore, as shown with the PARMLIB datasets, are not being fully restored. Doing checks on the dumped datasets show that the data is there but seems to disappear when restoring. Anyone with any idea as to what on earht is happening, TIA? ---------------------------------------------------------------------- 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
