Dubbing is part of the setup overhead for a task, and only occurs once, so except for very short tasks it is just noise in measuring performance.
As for the general overhead of Unix System Services, the Devil is in the details. For a comparison to be reasonable, the two programs have to be using the services in a comparable fashion. Was your COBOL programmer really comparing the overhead of conventional access methods to Unix file I/O, or were the numbers drowned out by, e.g., differences in application logic? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of René Jansen [rene.vincent.jan...@gmail.com] Sent: Friday, June 2, 2023 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 3.1: Now UNIXR Certified Less interesting then what to call it, is how it works out. I always found the interesting part that you can write a program and call SVC's using macros and Unix services from the same program. I found a number of people thinking that Unix is in some way 'emulated' and some really were calling USS 'the z/OS Unix emulator'. This is, of course, beside the truth, But some of the consequences of the design are felt; a COBOL programmer at a site that I worked at a number of years ago went to great lengths to show that file I/O was a great deal slower on ZFS than using the conventional MVS I/O. I found that strange because I remember the discussion between the OMVS people and the MVS people about how you could never trust I/O if the result was not committed to disk - and Unix is great in believing I/O has ended if the buffer has been updated. So it must have been the MVS I/O access method people that have won out that battle in the end. Also, the dubbing of address spaces and overhead which is incurred in various Unix services must slow down the thing a lot. But the design has turned out very well on the modern machines where speed is not an issue. I have seem many applications that are now running on USS and would not be on the mainframe if it were not for this subsystem. A point of concern is that a lot of those USS applications are not written by people who know the advantages of mainframe architecture; I think a great selling argument for AI involvement in coding would be to rewrite code for the right architecture; in more ways than a compiler can. best regards, René. > On 2 Jun 2023, at 16:16, zMan <zedgarhoo...@gmail.com> wrote: > > Of course in some ways OMVS is a shim in that MVS is still there > underneath. I assume David's point is that it's not JUST a layer that > directly maps to the obvious existing services, but adds additional value > on top of that. And Metz is saying that nevertheless, since MVS is still > there, he considers it a shim. > > You're both right; a bit more comity would increase the value of your > posts... > > On Fri, Jun 2, 2023 at 9:51 AM Seymour J Metz <sme...@gmu.edu> wrote: > >> Have you stopped beating your wife? Has I meant that I would have written >> it, so please stop trying to put words in my mouth. >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> ________________________________________ >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf >> of David Crayford [dcrayf...@gmail.com] >> Sent: Friday, June 2, 2023 9:42 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: z/OS 3.1: Now UNIXR Certified >> >> Haha. You said it. So you think OMVS and Cygwin are similar. LOLZ. >> >>> On 2 Jun 2023, at 21:33, Seymour J Metz <sme...@gmu.edu> wrote: >>> >>> That sure sounds like "a shim or abstraction layer" to me. >>> >>> >>> -- >>> Shmuel (Seymour J.) Metz >>> http://mason.gmu.edu/~smetz3 >>> >>> ________________________________________ >>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on >> behalf of David Crayford [dcrayf...@gmail.com] >>> Sent: Friday, June 2, 2023 1:06 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: z/OS 3.1: Now UNIXR Certified >>> >>>> On 2/6/2023 1:20 am, Seymour J Metz wrote: >>>> How do you think that IBM implemented HFS and zFS? It's all STARTIO >> under the covers, the same as for, e.g., QSAM, VTAM. >>>> >>>> The same for other OS services. Nothing from OpenEdition through Unix >> System Services ran on bare metal; it all used MVS services. That's in >> stark contrast to Linux on z, which does its own SSCH, dispatching, etc. >>> >>> I never claimed that it runs on bare metal. That was your assumption. >>> What I meant to convey is that it's not simply a shim. Let's take the >>> example of the sleep function. When you call sleep, it's not just a thin >>> API layer that directly calls STIMER. Instead, the syscall invokes a PC >>> which executes code within the OMVS kernel. This program has an entry in >>> the process table, can be interrupted by signals, and so on. Whether or >>> not it utilizes MVS services is not relevant to my point. It's simply >>> stating the obvious.. >>> >>> >>>> >>>> -- >>>> Shmuel (Seymour J.) Metz >>>> http://mason.gmu.edu/~smetz3 >>>> >>>> ________________________________________ >>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on >> behalf of David Crayford [dcrayf...@gmail.com] >>>> Sent: Thursday, June 1, 2023 9:50 AM >>>> To: IBM-MAIN@LISTSERV.UA.EDU >>>> Subject: Re: z/OS 3.1: Now UNIXR Certified >>>> >>>>> On 1/6/2023 9:40 pm, Seymour J Metz wrote: >>>>> It's a real Unix subsystem, but it certainly uses native services, >> e.g., STARTIO. >>>> How does STARTIO relate to a UNIX kernel? The Linux kernel operates on >>>> nearly all platforms without requiring any understanding of proprietary >>>> I/O subsystems. >>>> >>>> >>>>> >>>>> -- >>>>> Shmuel (Seymour J.) Metz >>>>> http://mason.gmu.edu/~smetz3 >>>>> >>>>> ________________________________________ >>>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on >> behalf of David Crayford [dcrayf...@gmail.com] >>>>> Sent: Thursday, June 1, 2023 9:36 AM >>>>> To:IBM-MAIN@LISTSERV.UA.EDU >>>>> Subject: Re: z/OS 3.1: Now UNIXR Certified >>>>> >>>>> On 1/6/2023 9:22 pm, Rick Troth wrote: >>>>>> On 6/1/23 06:27, Matt Hogstrom wrote: >>>>>>> Similar experience. Not sure if its the same person but I had >>>>>>> dinner with Jeff Nick (former Felllow with Z) and his story was that >>>>>>> they needed Posix to meet a Federal requirement. He also said that >>>>>>> it was contentious internally and so they assembled a team and >>>>>>> isolated them from the others so they could make fast progress. >>>>>> Dunno where it fits into the story, but I noticed that they used >>>>>> Mortice Kern Systems "MKS Toolkit" for much of the required Unix/POSIX >>>>>> utilities. (In Linux land, we'd say "the user space stuff".) >>>>>> That impressed me because MKS Toolkit did the same thing for MS >>>>>> Windows, a very rich approximation of Unix on top of another system. >>>>>> Leveraging MKS TK was a brilliant step. >>>>>> >>>>> It cost IBM a ton of money to take ownership of the MKS code. The >> kernel >>>>> space (OMVS) is implemented using two PC routines that implement the >>>>> syscalls. IIRC, one is SS and the other is CP, so they must have >>>>> different functions. Either way, OMVS is a real UNIX subsystem running >>>>> on z/OS. It's not a shim or abstraction layer on top of native >> services. >>>>> >>>>> >>>>>>> In an update on how they were doing they were finally able to fork a >>>>>>> process. He said it was more like foooooooooorrrrrrrrkkkkkkkk. >>>>>>> Clearly, they fixed the performance and little did they know that it >>>>>>> was such a critical decision for the platform that it saved z/OS. I >>>>>>> think K8s is the USS of yesteryear. No one knows it yet but it will >>>>>>> add another 25 years to the platform. >>>>>>> >>>>>>> Matt Hogstrom >>>>>>> PGP key 0F143BC1 >>>>>> 0xF4292E2D2B970780 and others >>>>>> >>>>>> >>>>>>>> On Jun 1, 2023, at 05:34, David Crayford<dcrayf...@gmail.com> >> wrote: >>>>>>>> >>>>>>>> I've worked with a few ex-OE guys, including my close colleague who >>>>>>>> used to the IBM DE running the OE project out of POK. Let me tell >>>>>>>> you, some of the stories they have are absolutely fascinating! It's >>>>>>>> my understanding that the POSIX certification was mainly pursued to >>>>>>>> meet the requirements set by NASA. But here's an interesting twist: >>>>>>>> NASA doesn't run a mainframe anymore. >>>>>>> >> ---------------------------------------------------------------------- >>>>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>>>> send email tolists...@listserv.ua.edu with the message: INFO >> IBM-MAIN >>>>>> ---------------------------------------------------------------------- >>>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>>> send email tolists...@listserv.ua.edu with the message: INFO >> IBM-MAIN >>>>> ---------------------------------------------------------------------- >>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>> send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN >>>>> >>>>> ---------------------------------------------------------------------- >>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>> send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN >>>> ---------------------------------------------------------------------- >>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>>> >>>> ---------------------------------------------------------------------- >>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > > -- > zMan -- "I've got a mainframe and I'm not afraid to use it" > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
