So I just tested this again to make sure I'm not spouting nonsense. Here are the steps that I took to reproduce the problem;
- I start an IEFBR14 job that allocates an arbitrary non-existent dataset with DISP=MOD, which specifies VOL=SER=NOVOL. NOVOL does not exist on our system. -> Because the volume does not exist, IEF238D is issued. - D GRS,RES=(SYSIEFSD,*) gives me; SYSNAME JOBNAME ASID TCBADDR EXC/SHR STATUS xxxx xxxxxxxx 0178 008FF260 SHARE OWN The jobname is the job that is holding the purposely misbuilt DD. - I try to V <dev>,CONSOLE. The device is actually a valid console defined in CONSOLxx. It functions properly as long as I'm able to vary it. A IEE799D (VARY CONSOLE DELAYED - REPLY RETRY OR CANCEL) message is issued. One of our OPS rules automatically and immediately replies CANCEL to this message. If I remove the OPS rule, respond with RETRY, and am fast enough with displaying GRS information (SYSIEFSD,*), I can see my user A/S queueing itself for an exclusive ENQ. - 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. - 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. - If I cancel the job that issued the IEF238D because the volume it needs does not exist, the 3390 volume from the previous step that is now pending offline is actually brought offline and is no longer accessible. I didn't try replying a RETRY to the IEE799D after cancelling the job, because OPS does it for us as soon as it's issued (could have turned that rule off again). But varying the device to console after the test-job was cancelled does properly vary the device to console, making it function and behave as it should on the visible end. 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. _Jan -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Don Williams Sent: dinsdag 25 augustus 2015 7:45 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vary <dev>,console with an IEF238D outstanding. Sadly, as previously stated, MVS has always worked this way. During allocation recovery, no new allocations can be processed. I agree that a RFE would be nice. Perhaps allocation recovery could be by device class. That way a DASD or tape allocation recovery would not block a console allocation. On Tue, Aug 25, 2015 at 11:09 AM J O Skip Robinson <jo.skip.robin...@sce.com> wrote: > I believe that MVS has always worked this way. With a mount pending > ('reply device name or cancel'), allocation holds up all other mounts ('v > xxx,online') until the uncertainty is resolved. The reason as I understand > it is that multiple mounts against the same device could cause an integrity > problem. The fact that one device is DASD and the other a console might be > justification for a bit more intelligence in allocation. > > The real culprit in OP's case the outstanding mount for a non-existent > device. In our shop, MIA (CA) manages all tape so that IEF238D is never > issued for tape. Hence we have an automated reply of CANCEL in the event of > a finger check in JCL. > > BTW IEE799D for console is handled by Auto-Reply (AUTOR00) this way: > > Msgid(IEE799D) Delay(30S) Reply(CANCEL) > > That is, if the message remains outstanding for 30 seconds, Auto-Reply > cancels the request. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
