If it's APF authorized, the STC can write a user SMF record.Then you don't have to worry about buffering, writing the data, filling up the output file, serialization of I/O, any of that stuff. SMF handles all that for you.
Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Sat, Jun 18, 2022 at 12:51 PM Charles Mills <charl...@mcn.org> wrote: > 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
