On Sun, 7 Sep 2025 18:08:10 -0500, Jon Perryman wrote: > >I should have said "many" people. I'll assume you know how to multi-task TSO >commands and REXX. What is your explanation why TSO and ISPF do not support >multi-tasking? > Perhaps the developers didn't understand multitasking. Or concluded that the benefit didn't justify the development cost.
>What is the problem with using UNIT=VIO or in storage VSAM? Do you think pipes >is doing something different? > It uses page space, which may incur the I/O cost of swapping. >>can a downstream step take timely action on output >>from an upstream step? This is routine design in >>CMS Pipelines. > >Is there no possible z/OS alternative? Are you saying this is how the >performance sysprog wants you to do this in z/OS? You do this in CMS, what is >the downside? 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. >>Pipelines cannot run two CMS stages concurrently. > >Which is it? You just said "timely action" which implies multi-tasking instead >of waiting for the completion of the previous stage. > 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. >> MVS ATTACH does >>that well, with some restrictions due to the kludge of the alternate DDNAME >>list. 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? >>ADDRESS ATTCHMVS for compatibility. But, ironically, that >>does not support multitasking, at which some people, contrary >>to your prejudice, are competent. > >Since you understand multi-tasking, please tell us when should ADDRESS >ATTCHMVS be used instead of ADDRESS LINKMVS. > 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. >There are several people here who easily handle multi-task. But there are >equally as many who think they understand it. It's not prejudice when the >answers require an understanding the entire audience. > There will always be uninformed readers. Don't let them set the standard. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
