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
