> Porting applications to Linux-s390x has never been particularly difficult.
It starts getting hairy when attempts are made for vectorized apps, or other acceleration frameworks that are available for x86 Intel or AMD. Can't port all of them but maybe need to re-create them, to have the same capabilities on Z. - KB ------- Original Message ------- On Tuesday, June 6th, 2023 at 2:25 AM, Rick Troth <tro...@gmail.com> wrote: > Porting applications to Linux-s390x has never been particularly difficult. > The biggest challenge has always been such things as endianness. > Linux-s390x presents the same kernel interface to userland as Linux-i386. > > Porting to USS has (at least) two significant hurdles: EBCDIC and a > different system interface. Being Unix certified doesn't really help the > porting process. > Even so, I wish that more packages would be ported to USS. It's better > FOR ANY GIVEN PACKAGE that it be ported to USS (and/or to other Unix, > such as Slolaris or AIX). The more broadly a package ports, the better > the health of its heart/core. > But I'm not being altrustic: I wish that they were available on USS. I > miss them! > > -- R; <>< > > > > On 6/5/23 11:01, kekronbekron wrote: > > > True, however, I expect it to at least be less difficult than it was in the > > past. > > Less difficult that it was with linux/s390x. > > Some of the key things IBM has done (and is doing) are > > LinuxONE community cloud, > > Wazi as a Service (on IBM cloud), > > and upstreaming LLVM and Golang bits. > > > > Icing on the cake will be zDT Learner's Edition, if it ever sees the light > > of day again. > > > > Are there any other noteworthy ports that haven't been upstreamed to > > because of this? > > > > - KB > > > > ------- Original Message ------- > > On Monday, June 5th, 2023 at 5:31 PM, David Crayford dcrayf...@gmail.com > > wrote: > > > > > On 5/6/2023 7:42 pm, kekronbekron wrote: > > > > > > > > porting RocksDB > > > > > Is zOS support upstreamed too, by any chance? > > > > > > The likelihood of the Meta maintainers accepting a z/OS patch PR is > > > extremely low. Due to z/OS being a niche platform, maintainers tend to > > > be hesitant in accepting patches unless they are supported by > > > organizations such as IBM (in the case of Node.js) with a commitment to > > > support the port. A notable example is the Perl community, which faced > > > significant challenges when removing EBCDIC support after the original > > > porters (IBM) lost interest. As a result, it is more commonplace to > > > maintain a separate patch file for z/OS-specific modifications. > > > > > > > - KB > > > > ------- Original Message ------- > > > > On Monday, June 5th, 2023 at 4:35 PM, David Crayford > > > > dcrayf...@gmail.com wrote: > > > > > > > > > One compelling reason to embrace zFS is its potential for > > > > > modernization > > > > > and facilitating the development of contemporary tools. While > > > > > acknowledging the significance of QSAM, VSAM KSDS, and other older > > > > > technologies, it is crucial to recognize the advancements made in data > > > > > structure formats for disk files since the days of VSAM. In the > > > > > present > > > > > era, LSM-trees have gained popularity for their application in NoSQL > > > > > key-value stores, blazing-fast TSDBs, and highly optimized logging > > > > > systems. > > > > > > > > > > Attempting to implement an LSM-tree using VSAM would be an arduous > > > > > endeavor, bordering on a nightmare. Even with the assistance of Media > > > > > Manager, it remains a Herculean task to reconcile these two disparate > > > > > technologies. > > > > > > > > > > I dedicated a couple of hours to porting RocksDB, and the results have > > > > > been nothing short of exceptional. It operates seamlessly on z/OS, > > > > > demonstrating its prowess and resilience. Another noteworthy aspect of > > > > > LSM-trees is their inherent ability to merge and compact while in > > > > > operation, eliminating the need for reorgs. > > > > > https://github.com/facebook/rocksdb > > > > > > > > > > https://www.youtube.com/watch?v=I6jB0nM9SKU > > > > > > > > > > On 5/6/2023 5:55 pm, David Crayford wrote: > > > > > > > > > > > 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 metzsme...@gmu.edu 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 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
