On Thu, 5 Jul 2018 14:23:35 -0400, Hobart Spitz wrote: >I think a more encompassing approach would be for JOL to be a function, >command or environment which could be invoked from REXX. > I wonder how JOL addresses theneed for "parallel ENQs". S99WTDSN requires APF authorization. Does JOL submit "optimized" JCL, or is it authorized so it can do all the initiator does to run a mix of authorized and unauthorized steps.
>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, ... > Why would one want to? > ... and the foreground scripting languages can be useful in >background, but aren't. ... > There's IRXJCL and IKJEFT*. > ... z/VM has never had a separate batch scripting >language, and it still can do things that z/OS was never designed for. > UNIX has never had a separate batch scripting language. >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. > I'm confident that ENQ serializes all affected systems so the action of any single ENQ call appears instantanteous to the caller and to all other jobs on any systems. >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. >*/* The "retry and recover" must FREE all resources held and start ab ovo in order to avoid deadlocks. And that might lead to unacceptable thrashing. (Most of your sample code was flowed illegibly. How'd you do that?) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
