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.
.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[email protected]
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Shmuel Metz (Seymour J.)
Sent: Tuesday, August 25, 2015 7:02 AM
To: [email protected]
Subject: Re: vary <dev>,console with an IEF238D outstanding.
In
<2684875177256404.wa.elardus.engelbrechtsita.co...@listserv.ua.edu>,
on 08/25/2015
at 04:45 AM, Elardus Engelbrecht <[email protected]>
said:
>Thanks. After RTFM, now I see the whole story. Interesting, perhaps you
>discovered a bug.
No bug; CONSOLE uses the same allocation code as any other job, which includes
an ENQ. I'd suggest an RFE.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
