On Sun, 7 Sep 2025 15:58:07 -0500, Paul Gilmartin <[email protected]> wrote:
>>Multi-tasking 102: TSO and ISPF do not multi-task because people >>do not understand multi-tasking and would abuse it. >>TSO PIPEs are not acceptable because it encourages multi-tasking. >> >I hear the arrogance alarm. Don't thus demean your colleagues. 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? >>Pipes 101: The most rudimentary z/OS PIPE is batch (step 1 feeds step2 that >>feeds ... that feeds step #). >> >Can batch do this without using a temporary data set? What is the problem with using UNIT=VIO or in storage VSAM? Do you think pipes is doing something different? >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. >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. > 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. >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. 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. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
