On Sun, 7 Sep 2025 19:59:55 -0500, Paul Gilmartin <[email protected]> wrote:
>Earlier, you said LINK, not LINKMVS. LINK supplies a CMS-format PLIST; >LINKMVS and ATTCHMVS supply a CALL-compatible PLIST. But I >consider ATTCHMVS a travesty. It performs ATTACH then WAITs for >completion. No concurrency. You said you understood multi-tasking. While multi-tasking requires an ATTACH, ATTACH does not imply multi-tasking. Ask yourself why JES initiators do an ATTACH and go into a wait. What about TSO TCBs all in wait? IMS dependant regions? There are many TCB's not used for multi-tasking. TCB's have resources that must be managed and ATTCHMVS sole purpose is to clean up resources before REXX terminates. ATTCHMVS is critical to long running REXX. Resources during LINKMVS are indistinguishable from REXX resources which for a short time is not a problem. ATTCHMVS allows misbehaving programs to be called by reducing their impact. >>What is the problem with using UNIT=VIO or >> >It uses page space, which may incur the I/O cost of swapping. That same cost exists with PIPEs. >>Is there no possible z/OS alternative? Are you saying this is how the >>performance sysprog >>wants you to do this in z/OS? In z/OS, does it impact CICS, IMS, DB2, MQ and >>more. >> >If it hurts, don't do that. I'm not discrediting alternatives in some cases. What you're saying is to hell with the performance sysprog (who didn't do that). Instead, let's rely on application programmers who you believe is far better educated in performance, and will know "not to do that". >The "CMS" stage may run a Classic CMS program object. >Those are not designed to support concurrency. Therefore >Pipelines CMS locks, prevents any concurrent stage. >Multiple REXX and builtin stages may run concurrently. So you're saying CMS PIPEs only multi-tasks for BUILTIN stages. If you ignore BUILTIN functions, then you have the same thing a z/OS batch using VIO. Unix pipes multl-task for all stages but some here are saying it's inefficient. >>> It should have been possible to make DDNAMEs have task scope >>>optionally, instead of job scope. >> >>That ship sailed back in the 1960's. I wouldn't want to debug DDname reuse. >> >If a Court of Appeals rules against it, must it return to port? ROTFLOL, IBM addressed task related DDname conflicts decades ago because it was a basic multi-tasking problem. You don't change the JCL. Instead, you change the DDname in the DCB or ACB (e.g. DFP, sort, IEBGENER, IEBUPDTE and ...). How do you think REPRO INFILE(aaa) OUTFILE(bbb) works? I have never encountered a task related DDname could not be easily solved. Who do you perceive needs task DDnames? Not CICS, IMS, TSO, batch JCL or ...? You ignore that TSO design is single threaded. ISPF ISPTASK multi-tasks but it has LM and ALLOC to dynamically assign a unique DDname. If you're an application programmer and you don't understand how to override DDnames, then realize the fixed DD is yours to change until you return to the display. Just complete the work before returning to the display and it's guaranteed. As long as all ISPTASKs follow this rule, no problem exists. Worst case, save the DD and restore it. If task DDnames are your only viable solution, then do it through a subsystem file. It's not difficult. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
