My thinking was that part of the parallel allocation would be to free existing allocations, but there might be issues with that.
If there is no business case for an incremental improvement than there certainly isn't one for a total replacement. Given the control block structure for starting a new address space and allocating its data sets, that would be a massive effort. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of Paul Gilmartin <0000000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, July 11, 2018 2:51 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: REXX as JCL replacement On Wed, 11 Jul 2018 18:09:21 +0000, Seymour J Metz wrote: >You keep missing the point that REXX does not currently provide the >serialization >that is available through JCL. Rewriting the job as a REXX script that does >not do >the necessary serialization is a CLM. > ??CLM?? >That's why I suggested a parallel allocation facility usable from REXX. > In order to avoid deadlocks, that parallel allocation facility must be invoked only once, and before any other SYSDSN ENQs are extant. There might be a way: launch the Rexx script from Unix System Services. Better yet, support //SYSEXEC DD PATH='/...' so no static ENQs are needed. RFE material? >I don't like JCL, but I don't see any way forward other than incremental >improvements. > Business case for those? And trimming the whiskers from JCL would create compatibility problems for users who have come to depend on them, even if only as circumventions. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
