On Mon, 8 Sep 2025 06:45:45 +0000, Farley, Peter <[email protected]> wrote:
>A great deal of your arguments seem to me to be about the performance >impact of a multitasking program on other-system-critical applications, I'm discussing why TSO PIPEs no longer exist. I'm saying that people use them because they are perceived as performant. I'm debunking that myth. There are alternatives that could be made as performant that don't involve PIPEs. >How is the performance of one truly multitasking batch step any different from >any other WLM-managed batch job? Batchpipes involved 2 or more jobs. Should IBM implement batch enclaves? Or maybe IBM should implement multi-tasking JCL definitions? >You seem to be arguing that a multitasking batch job step in a production >batch stream could interfere >with the priority-CPU-I/O of the online and real-time and database activities >running on the same system(s). I'm saying that batchpipes most likely failed because it ignored performance. I'm saying that batchpipes removes control and understanding by the performance sysprog. >I just don’t understand why you are so dead set against pipes for "allowing" >multitasking >to be more easily created by "ordinary" programmers. I'm not against pipes, however PIPEs are designed for uncomplicated environments that don't have sysplex, srm, sysprogs and more. z/OS is designed for sysprogs making choices whereas Unix is about application programmers pretending to be in charge. How many times will Unix distributed computing be allowed to fail (now moving on from Kubernettes to micro services)? SYSPLEX has been around for at least 30 years while Unix develops a new distributed solution every couple of years. Doing things right the first time is uniquely mainframe. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
