While BLKSIZE has no meaning for linear data sets, it *does* have meaning for the BSAM compatibiliy interface.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Jon Perryman <jperr...@pacbell.net> Sent: Monday, November 13, 2023 1:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: UNIX "BLKSIZE"? On Mon, 13 Nov 2023 09:11:19 -0600, Paul Gilmartin <paulgboul...@aol.com> wrote: >>On Mon, 13 Nov 2023 01:10:14 -0600, Jon Perryman <jperr...@pacbell.net> wrote: >>z/OS Unix filesystems are linear datasets. >No. BLKSIZE is not ignored. Incorrect, BLKSIZE has no meaning for VSAM linear datasets. By definition, "All linear data set bytes are data bytes" which is how a Unix filesystem functions. > It is merged into the DCB by OPEN, > or supplied by SDB if not otherwise specified. A Unix file is always 1 logical record. BLKSIZE has no meaning in this context. While BLKSIZE is stored in the DCB the subsystem ignores it. Any part of that logical record can be processed or in its entirety (e.g. read or write at offset 1000 for 100 bytes). > for BSAM it affects how many times the WRITE/CHECK is issued, This is conjecture because logic for BSAM communications to the Unix file subsystem is not made publicly. I suspect that CHECK is a simple BR14 but maybe IBM bypassed this logic. BSAM CHECK has no meaning because the subsystem will determine to do VSAM CHECK because it must remain compatible with UNIX. As for the WRITE, we don't know if every program write causes a transfer to the file subsystem or if BSAM buffers according to the BLKSIZE before sending to the subsystem. I'm not willing to venture a guess because there are pro's and con's to both methods. > and probably has some effect on performance for QSAM. I'm guessing that performance benefit is insignificant. More important is the adverse effect of buffering by BSAM / QSAM. It violates the UNIX standard of concurrent writes to a file. Most people don't think about the impact of this logic which says you have a file open 20 times, the records will be interleaved according to the time the write occurred. Instead of immediately adding each record, BSAM / QSAM buffering would delay adding the records to the file causing them to be out of sequence. I simply can't see IBM enabling BSAM / QSAM buffering that would confuse Unix programmers, but I could be wrong. ---------------------------------------------------------------------- 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
