On 2018-07-03, at 08:58:26, Tony Thigpen wrote:
> *PLEASE* don't re-invent the wheel. z/VSE has had this for 15+ years. We have
> had time to shake out the issues.
>
Yes, but would it be feasible to port these to z/OS? Something like
the enhancements to DYNALLOC that Shmuel discusses. It can't be done
entirely by enhancements to the Rexx interpreter.
Does z/VSE perform multiple allocations with no deadlock hazard?
> We also have ways to provide SYSIN and capture SYSLST:
> CALL OUTTRAP idcams_output.
>
> CALL REXXIPT idcams_input.
>
For generality, these should have a DDNAME operand; an
enhancement such as:
call outtrap "sysprint_stem. (dd sysprint"
call outtrap "sysut2_stem. (dd sysut2"
call rexxipt "sysin_stem. (dd sysin"
call rexxipt "sysut1_stem. (dd sysut1"
(I certainly recommend quoting symbol names to prevent evaluation.)
address LINKMVS "IEBGENER"
(Neither LINK nor LINKPGM provides a z/OS compatible plist.)
Would Pipelines provide an alternative to (enhanced) OUTTRAP
and REXXIPT? I've asked a similar question on CMS-PIPELINES
but always been misunderstood. The answers told me of stages
to connect to the other end of the DDNAME.
> Seymour J Metz wrote on 07/03/2018 10:32 AM:
>> When you reinvent the wheel, please make them round. A procedural
>> replacement for JCL has all sorts of issues, regardless of syntax. Instead,
>> why not
>> 1. Enhance Dynalloc to have a parallel allocation function.
>> 2. Enhance IRXJCL to allow a script in a sequential dataset.
>> 3. Enhance REXX to support parallel allocation.
>> The installation could then provide custom procedures for invoking IRXJCL
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
