Adverse blocking: exactly; that is why I started this thread. Crash recovery: on restart continue appending onto this month's (UNIX) file; proceed as normal. With a whole lot of bad timing luck I might lose one record. It's not financial data; the data will barely be missed.
Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, June 21, 2022 7:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Some UNIX file usage questions On Mon, 20 Jun 2022 21:55:07 -0700, Charles Mills wrote: >> But is loss of a single record disastrous? > >No, I said earlier, this is not banking transactions where a lack of 2-phase >commit risks losing a bunch of money between the cracks. > What's your crash recovery plan? o Create a new file and process both at report time? o Continue writing to the same file with O_APPEND? Long ago, I reported an apparent I/O performance problem. Support examined my code and explained that I used O_APPEND, which incurs significant serialization overhead. I assume this is to preserve integrity if multiple jobs write to the same log file. (I mentioned this on MVS-OE and WJS quickly jumped in, saying he didn't recognize the behavior, but a sysplex might add overhead. He'll be missed when he retires at the end of the month.) The cost of O_APPEND is likely to be insignificant for your expected traffic. And you don't expect multiple writers. I'd expect it to be worse for Classic data sets: ALLOCATE DISP=MOD OPEN PUT one record CLOSE FREE (Adverse blocking!) -- gil ---------------------------------------------------------------------- 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
