Hi Malcolm! We tried the setup you suggested, and worked as we wanted it!
Thanks! Mauro http://mauro.limeiratem.com - registered Linux User: 294521 Scripture is both history, and a love letter from God. 2013/5/16 Malcolm Beattie <[email protected]> > Mauro Souza writes: > > Hi guys, > > > > I have a client with a peculiar problem. They have zVM 4 partitions, > > sharing the same LCU's, every partition sees every DASD, and each > partition > > have its own range of disks, defined with Offline_at_IPL on SYSTEM > CONFIG. > > They use this setup because some times they need to access in one > partition > > a disk belonging to another. > > > > When this need arises, they issue a VARY ON 2345 and get the disk online, > > use it, copy something, VARY OFF 2345. Works fine. > > > > The problem: some channels are getting offline sometimes. We know that > > people are always messing with the cables, and from time to time one > fiber > > or another gets loose, they fix, and so on. And when the device comes > back > > online, every single DASD on that CHPID comes online too, ignoring the > > Offline_at_IPL statement. As it should, because Offline_at_IPL is just > for > > IPL. > > > > We are thinking on a "method and apparatus" for getting those DASDs > offline > > when the CHPID gets back to life. I already have a REXX (I just deleted a > > lot of lines of CPSYNTAX and added a few more) that parses SYSTEM CONFIG > > and looks if a given DASD is in the Offline_at_IPL range, and can put a > > DASD offline. I just could not make the exec run by itself (or by MAINT, > or > > another CMS machine) every time a channel status changes. > > > > I tried to setup PROP, and it looks fine, except it doesn't react at all. > > My PROP RTABLE is configured to run my exec, but when the channel gets > > back, it does nothing. If I send the message by hand from MAINT, the exec > > runs, and puts the device offline if it is on Offline_at_IP range. I > guess > > I will have to read everything about PROP again (I could find few > > documentation and examples), in case I have missed something. > > > > I saw the NOTACCEPTed statement for DEVICES on SYSTEM CONFIG, but looks > > like it will take the device offline forever, and we will need to bring > it > > online sometimes. > > > > Does anyone have any idea for us? > > "NOTACCEPTED" is reversible: provided you have# > "FEATURES ENABLE SET_DEVICES" in your SYSTEM CONFIG, you could try doing > CP VARY OFFLINE rdev > CP SET DEVICES NOTACCEPTED rdev > > and see if that prevents the disappearance/reappearance of the > channel triggering it coming online again. The CP Commands and > Utilities Reference describes the behaviour as: > NOTACCEPTed > tells CP not to accept the specified device or devices when the > device(s) is dynamically added to VM from another partition. When > VM is running second level it will prevent a device(s) from > being accepted when a device is attached to the virtual machine > in which VM is running. If VM dynamically defines a device for > its own partition the NOTACCEPTed designation is overridden. > > and it's not completely clear to me which case is covered by > "channel reappears". Worth a try though. Bringing it online again, > you should only need a > CP VARY ONLINE rdev > > CP still will retain some knowledge of the device though, so if that > doesn't work and you want CP to forget about it even more (though > still not entirely), you could try > CP VARY OFFLINE rdev > CP SET RDEVICE rdev CLEAR > CP SET DEVICES NOTSENSED rdev > CP SET DEVICES NOTACCEPTED rdev > > After that lot, to bring it back with default DASD options you'll > want something like > CP SET DEVICES SENSED rdev > CP VARY ONLINE rdev > > or, if you want non-default settings for the rdev's setting of > SHARED, EQID or MDC, you'll need instead an explicit > CP SET RDEVICE rdev ... TYPE DASD ... > which includes your options, followed by > CP VARY ONLINE rdev > (maybe preceded by > CP SET DEVICES ACCEPTED rdev > CP SET DEVICES SENSED rdev > for the sake of completeness). > > --Malcolm > > -- > Malcolm Beattie > Mainframe Systems and Software Business, Europe > IBM UK > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
