Fifteen years ago Unix System Services was already trailing edge and it is hard to explain a refusal to use it on any basis but xenophobia. Does it have warts? Abundantly, but so do many other things that don't get the same reaction.
OTOH, benchmarks are tricky things, and it is often easy to get the answers you want by carefully cherrypicking the details. I suspect that QSAM really is faster for the test he ran. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of David Crayford [[email protected]] Sent: Monday, June 5, 2023 5:55 AM To: [email protected] Subject: Re: z/OS 3.1: Now UNIXR Certified On 2/6/2023 11:31 pm, René Jansen wrote: > What I remember of it is that he was convinced it was a lot slower. He was mistaken! I've tested it out, and QSAM is no match for zFS. You can find the details in this gist: https://gist.github.com/daveyc/14b45d6d70d8dd9af1848e539d78881f. Adding an fsync() call after writing each record barely incurs any overhead. zFS, operating with highly optimized Media Manager APIs, handles it efficiently. Additionally, zFS functions as a caching file system. I have observed a certain degree of snobbery among many traditionalists when it comes to USS. I can recall an incident from approximately 15 years ago when I advocated for the use of sqlite in one of our products. My boss dismissed the idea, expressing concerns that customers might be deterred by using the UNIX file system. Consequently, we opted for a VSAM KSDS, despite its inherent limitations. Interestingly, it is worth noting that there are now numerous IBM z/OS products that embrace sqlite, with some even integrating it with HLASM. > So I told him that nobody forced him not to use QSAM for datasets just > because it ran in USS. And it think that is a great asset of it. Just because > Unix forces you to have a hierarchical directory system does not mean, in > USS, that you need to use it for all I/O. > > René. > >> On 2 Jun 2023, at 17:03, Seymour J Metz<[email protected]> wrote: >> >> 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 >> > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email [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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
