> - I try to vary a 3390 device ONLINE that was previously OFFLINE. This works > without any problems and I can access the associated volume immediately. That means that the SYSIEFSD ENQ had a minor of VARYDEV, right? You may want to search for old apars with keywords sysiefsd, q4 and varydev.
> - I try to vary the same 3390 device OFFLINE, and I am met with; IEF524I > <dev>, VOLUME xxxxxx PENDING OFFLINE. (I reckon that the cause of this could > lie somewhere else altogether). D GRS,RES=(SYSIEFSD,*) does not list my user > as requesting/owning any ENQ, so I guess it is some other resource that is > needed. I would consider this typical z/OS behaviour - as long as *anything* is allocated to a UCB, that UCB will not go offline. Instead of checking for an ENQ, you should have checked the actual UCB - it probably still had a count of allocated jobs/asids larger than zero. Also, IIRC, setting a UCB offline (or online, for that matter) just flips the bit in the UCB control block - it does not really mean that you can access the volume (after a V online). I haven't tested this recently, but I seem to remember it is possible to vary online a device that has no paths. > So I'm not sure if I can follow you completely, Skip and Don, because I can > still vary other 3390 devices online, but not 3270 devices to console. From > another perspective it's only normal that I can vary 3390s online, because > that's exactly what needs to happen to make our (erroneous) job continue > processing. But that shouldn't necessarily break the varying of consoles. > Unless I'm completely missing something, which is absolutely possible since I > don't (yet?) have any knowledge of the internals. > Like I said, this doesn't break the OS, but it's interesting behavior > nontheless. Again a guess on my part: I believe the SYSIEFSD ENQ is needed exclusively because to vary a device to be a console, the UCB needs to get pinned. My (1.13) console is still pinned, so console restructure probably hasn't changed that part. You check this by going into IPCS browse, selecting 'active' as the 'dump' source and then issuing 'ip listu xxxx' with xxxx the ucb number. Field UCBSTAT has bit UCBALOC (x'80'), and that tells the system if anything is allocated to that UCB. UCBASID would show the asid, according to the UCBALOC description (For my console it shows x'0000', though). And the listu formatter tells you if the UCB is pinned in clear text. Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
