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
