The issue is not doing simultaneous ENQs; the issue is getting Allocation to do them, correctly and in a safe fashion. The major names in question are protected, to say nothing of the need for the ENQ to be done against the Initiator TCB.
IBM could certainly provide such a service, but we're not talking about 50 or a 100 lines of code; it's not intractable, but neither is it trivial. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of Charles Mills <charl...@mcn.org> Sent: Thursday, July 5, 2018 4:29 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: REXX as JCL replacement I have not really thought it through but I just cannot picture how building some combination of Rexx or whatever + assembler one could not do 'n' simultaneous ENQs. The facilities are there in MVS for the asking: "ENQ assigns control of one or more serially reusable resources to a task. If any of the resources are not available, the task might be placed in a wait condition until all of the requested resources are available." Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Hobart Spitz Sent: Thursday, July 5, 2018 11:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REXX as JCL replacement I think a more encompassing approach would be for JOL to be a function, command or environment which could be invoked from REXX. That way, you don't have to reinvent or do without all the things that REXX brings to the table, both as a language and as something that interfaces with many parts of z/OS. I.e., DB2, JES, ISPF, TSO, etc. I think CA also has a similar product. I don't know anything about it, or if it is used much. The existence of JOL and the CA product suggest that there is a wider need than realized to upgrade z/OS batch processing to more modern methods. Historically, IBM has had more scripting languages than platforms (z/OS: REXX, CLIST, JCL. z/VM: EXEC, EXEC2, REXX. AS/400: OCL.), and z/OS is the only major platform where the batch scripting language (JCL) can't run in foreground, and the foreground scripting languages can be useful in background, but aren't. z/VM has never had a separate batch scripting language, and it still can do things that z/OS was never designed for. I think Ward's question was well answered. I might add a few things later that were missed. (I have a long draft that is mostly redundant.) All that said, I'd like to come back to the primary, perhaps only, reason why REXX is not used more in batch: "Parallel ENQs", or the lack thereof. I use quotation marks because I am skeptical that anything like this can actually be truly simultaneous. On the other hand, the time scale on which ENQs are typically held means that near simultaneous is fast enough. BTW, if all updatable application data is stored in DB2 tables (e.g.) and/or all DISPs are SHR, there is no reason not to use REXX in batch. If DISP=OLD is never used there can be no deadly embrace. This is not theory. In the early 1990s, I did just such a project, replacing more than 300 JOB streams with less than 10 much smarter ones that began by invoking a REXX program. All updated data was in DB2, and we used a REXX-to-DB2 interface. Let's consider what a "Parallel ENQ" routine might look like. This should allow the approach to be explored and refined, proving/disproving the concept to site management and vendors, and help formulate the most appropriate RFE. Here a first draft, untested, for an external, preferably compiled routine: *AllocMlt:* */* REXX - Allocate dataset(s) to files(s). Retry and recover if needed. */* */* Arg syntax: DDName BeforeDisp[","NormDisp] Dataset... [")" options] */* */* Abnormal Disp to be handled by return code check and FREE in caller. */* */* We let ALLOC report problems with ENQs of concatenated datasets. */* */* Stop on the first failure; if we could send msgs. in fut., keep going.*/ * *Alloced. = 0 /* Track successes */* *do iA = 1 to arg() until RC <> 0 parse upper value arg(iA) with DDName Disp DSN /* Code RecFM, LRecL, DataClas, Space, etc. after DSN and ")". */ /* ALLOC allows concatenation via a list of dataset names. */ /* DSN may be a list if Disp not NEW or MOD. */ parse var Disp BeforeDisp "," NormDisp /* Like JCL. */ Status = sysdsn(word(DSN, 1)) if BeforeDisp = "ASIS" then BeforeDisp = word("new old", (Status = "OK") + 1) /* Allows skipping archaic use of IEFBR14. */ if wordpos(BeforeDisp, "OLD SHR") > 0 then do iTry = 1 to 5 while Status = "DATASET UNAVAILABLE" say time() DSN "unavailable, retrying." /* Would be important to send message to ENQ holder, esp. TSU. */ call sleep "10 sec" /* SLEEP may need to be written. */ Status = sysdsn(word(DSN, 1)) end iTry select when Status = "OK" & wordpos(BeforeDisp, "OLD SHR") > 0 then nop when subword(Status, 2) = "NOT FOUND" & * *wordpos(BeforeDisp, "NEW MOD") then* * nop otherwise /* Status incompatible with BeforeDisp, or other error. */ say "Attempting" arg(iA)", status" Status"." leave iA end "allocate reuse file("DDname")" BeforeDisp NormDisp "dataset("DSN Alloced.iA = (RC = 0) end iAif iA > arg() then /* Success */ exit 0/* Failure */do iA2 = 1 to iA if Alloced.iA2 "free file("word(arg(iA2), 1) end iAexit -iA* Any thoughts? Anyone want to try it out and post the results? SYSDSN() having the relatively new DATASET UNAVAILABLE value means there are other, possibly more creative ways to handle ENQ conflicts. OREXXMan JCL is the buggy whip of 21st century computing. Stabilize it. Put Pipelines in the z/OS base. Would you rather process data one character at a time (Unix/C style), or one record at a time? IBM has been looking for an HLL for program products; REXX is that language. On Wed, Jul 4, 2018 at 9:14 PM, zMan <zedgarhoo...@gmail.com> wrote: > > > > >What would it take for IBM to allocate just a couple of people to make > it > > available as a supported product? > > > > Having someone left in POK who knows how to code. Not sure there's anyone > left... > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- 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
