I don't know, give it a try; from LP1 define a device on LP2 that has a CU w/paths candidate/access lists. If LP2 has not_accepted it won't show up... w/o intervention, such as cp set accepted... then if you're wild enough to have 2 LPars w/DynIO enabled, you can steel the cookie and define a device from LP2 on LP2... I'm thinking it'll pop up, regardless of not_accepted, according to help cp set devices; if you don't have sensed set, you'll need to cp set rdev or attach it a guest. CP will build the RDEV blocks and RDCBK's, if light gets thru the director, to the cu interface and it'll be there for a vary online. Some time ago, we had a project to *conditionally* allow VM access to at least a simplex copy of TPF on-line dasd for a cmstpf build, Not_Accepted wasn't a lock for us and a CP EXIT we tried was a performance nightmare... but that is an entirely different story. ymmv. On Wed, Jul 14, 2010 at 3:10 PM, Schuh, Richard <[email protected]> wrote: > That may have been the original intent; however, customers always find ways > to use features that may not have been considered by the designer. If we > didn't, VM would have been a conversion tool with a 2 year life span. > > If a device is sensed and there is a device present, a VMDBK is built for it > regardless of its online/offline status. There may be other blocks created > for it as well. Making the device Not_Accepted prevents the sensing of the > device and the building of the blocks. It is possible to dynamically add the > device later using the DEFINE and SET commands, just as you would a device > dynamically added to the LPAR. > > Regards, > Richard Schuh >> > Regards, >> > Richard Schuh
-- Gregg Reed "No Plan, survives execution"
