Keep in mind that in the *ix world, spawning new processes is routine, and that means separate address spaces, at least by default.
I was never a fan of different departments only talking to each other over formal channels. Informal chats between applications and systems can lead to useful insights. No department has a monopoloy on knowled, intelligence or insight. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Farley, Peter <[email protected]> Sent: Wednesday, September 10, 2025 2:57 AM To: [email protected] <[email protected]> Subject: Re: Pipelines = you don't understand z/OS External Message: Use Caution Architecting a successful cross-address-space application is high-level hard, no matter who is doing it. If truly needed for a business application to accomplish a vital business function, so be it, but I wouldn’t try it without a LOT of help from ALL the technical teams in the shop. WRT “On z/OS, is the application programmer making decisions or does the sysprog play a vital role?”, of COURSE the systems-level team, the database team, the capacity and performance team, the networking team, the storage team – ALL of the teams have vital roles to play, in design review and in implementation recommendations and in problem solving during development and testing and in performance monitoring and tuning after production implementation, and last but definitely not least in solving post-production business and technical issues. My basic point is that it is not ONLY the sysprog‘s job, it’s the job of ALL the teams together to give the business whatever it needs to thrive. No single team has a “larger” responsibility than any other. Your sysprog job and responsibilities aren’t “bigger” than the application programmer’s, they are just in a different sphere with different scope. Your ideas and recommendations and knowledge of what works and what may not work are just one component in business application decisions. And it is not a democracy – in the end, business management makes the final choices for the best ROI they can get for the funding that they have. In a cooperative and knowledge-sharing environment, there should already be the talent and means to accomplish business objectives. In a siloed, protect-my-turf-at-all-costs environment, things usually go south faster than anyone wants to see. BTDTGTS. Let’s not foster or recommend siloes or turf battles please, because then no one succeeds. Peter From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Jon Perryman Sent: Tuesday, September 9, 2025 9:09 PM To: [email protected] Subject: Re: Pipelines = you don't understand z/OS On Tue, 9 Sep 2025 22:12:45 +0000, Farley, Peter <mailto:[email protected]> wrote: <Snipped> >When I think of PIPEs I mean a CMS-style pipe command implementation >usable in a single (possibly) multitasking process, True pipes are accessible across address spaces. > NOT, as you put it, “. . . designed for sysprogs making choices”. I've been told by many developers that they have full control. They love taking responsibility for security, efficiency and all other aspects. Do you consider DB2 for zLinux system level software despite using nothing more than TCP sockets. Which of the Unix distributed computing solutions is not application level design? On z/OS, is the application programmer making decisions or does the sysprog play a vital role? Application developers play a vital role in z/OS choices but sysprogs play a much larger role. In Unix, application developers play the only role and often make bad choices. BIG-O is clunky for optimizing a Unix application? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
