I guess you gave a R/O link to your secondlevel userid (i.e. 1913 is a R/O minidisk). Then, it is much better to issue ATTACH 1193 ESAMON 1193 R/O ACCESS 1193 X this way CMS will see it is a R/O disk, it will never try to write to it. With a simple ATTACH, CMS thinks it is R/W and if by some accident, CMS tries to write to it, it gets an I/O error and CMS abends.
Note too that you don't need to define all the firstlevel minidisks you want to use in the directory entry of VMTEST53. You can dynamically LINK: - go to CP read in your host system. If you didn't do anything special for TERM BRKKEY, simply press PA1 - then LINK xyz vaddr myaddr RR - BEGIN (to return to your z/VM 5.3 system You could even install the CPHOST package from VMs download lib, it will give you a new CP command to talk to the host VM. I assign "CP1" as commandname fort this exit. So, in the second level guest, I can issue "CP1 LINK xyz vaddra myaddr RR", or also "CP1 Q V 1193". CP exists can be installed without IPLing CP. 2007/7/26, Michael Coffin <[EMAIL PROTECTED]>:
Hi Anne, You are worrying too much about this. IPL your second level system. Execute "CP QUERY 1913". See it? It appears as a REAL DASD device (it's really a link to a VM minidisk). You can "use" that DASD device like any other device. So log on to your ESAMON userid second level, ATTACH 1913 to ESAMON. On ESAMON ACCESS 1913 X and voila, you have the "minidisk" accessed and can copy it's contents. -Mike
-- Kris Buelens, IBM Belgium, VM customer support
