I see no advantage to that over simply writing to a UNIX file (where there are no "block" issues). Why write and copy when I could simply write?
Serious question. What is the advantage of write-to-3390-and-copy-over as opposed to write-to-zFS? Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lennie Dymoke-Bradshaw Sent: Tuesday, June 21, 2022 12:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Some UNIX file usage questions If I read this correctly, you will be writing about 24 bytes 96 times a day. That is 2304 bytes. This will use less than 2 tracks of 3390. My copy of GX26-4577 shows that if the LRECL is between 23 and 56 bytes you get 82 records per track. So why not simply write 24 byte blocks and then each evening run a job to re-block the output data set and append to yesterday's data set? Or am I missing something? Lennie Dymoke-Bradshaw https://rsclweb.com 'Dance like no one is watching. Encrypt like everyone is.' -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Charles Mills Sent: 18 June 2022 17:52 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Some UNIX file usage questions Hope some of you can help out a dinosaur. <g> I am designing a z/OS application (for in-house use, not an ISV product). It will consist of a started task that runs continuously plus one or more small reporting programs, one of them to be run daily shortly after midnight. The started task will record a very small amount of data (about 24 bytes or so) every fifteen minutes, 96 times a day. That data will be input to the reporting program(s). Being a dinosaur, I thought in terms of recording that information in a traditional MVS dataset. There are some problems with that: basically if I do allocate, open, write, close, de-allocate then I think I am going to have 24-byte blocks on disk*, which is going to give me really poor track utilization; and if I don't, then the report program is not going to be able to read the dataset due to ENQ contention (absent some sort of special "close it for a little while around midnight" logic) and also any abnormal termination of the started task (such as an IPL) will cause a loss of data -- not a critical issue, but less than desirable. *Yeah, emulated blocks on emulated tracks. There are of course no real tracks anymore. But the emulation is pretty realistic, right down to the poor track utilization! I thought about various approaches such as accumulating the records in memory and then writing all 96 of them in a single blast right after midnight. That would probably work out and solve the ENQ problem (but not the IPL problem). It would unfortunately preclude any ad hoc reporting in the middle of the day. And I would still end up with fairly small 2K blocks. This morning I thought "why not a UNIX file?" I can of course look up any specific questions in the relevant manuals, but I am just unfamiliar with the big picture. Am I correct that (1) there is of course no "physical block size/track utilization" issue with UNIX files; (2) that shortly after I write a record it will be fixed in place and would survive an IPL or other abnormal termination of the writing task; and (3) most importantly, the report program can read the file while the writing task has it open? Are those premises correct? (By "shortly after" I mean that I could live with a delay of a few minutes or so; this is not a banking application where two-phase commit is critical.) I picture writing the started task in Rexx, so I would have to write to a DD name allocated to the UNIX file (either dynamically or with JCL), not with "native" C fopen(), fwrite(), etc. Does that change any of the answers? Anyone see any gotcha's with the UNIX file approach that I seem not to have thought of? Thanks! Charles ---------------------------------------------------------------------- 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
