As another poster pointed out, fopen / fwrite / fclose is similar to
QSAM PUT
and supports arbitrary block sizes; the block size you want can be
specified on
the DD statement or on fopen (IBM C extension).
From your original post I got the impression that you wanted to write
an invidividual file every 15 minutes, with only 24 bytes in it. This
would indeed
be a waste of space. That's why I proposed the single file with the
timestamps in it;
collecting the data over a longer period of time (day, week, month, ...).
And that's why the started task needs to fopen the file using mode =
append.
For the collision logic: you could also have the reporting programs writing
a certain file when they start and deleting this file, when they complete
and the started task doing the update only, when this file does not exist
(and wait or defer the update otherwise)
You should do an estimation, how long the reporting will take
and / or if it is better to copy the file for the reports into another file
(to allow concurrent updates) ... or: restrict the time for "utilities"
to certain "batch windows". I would also like to ask if the reporting
programs need to know the latest updates, or if a copy of - say - the
content of the file from last midnight is sufficient. If so, you could
copy the file some minutes after midnight for the reporting,
and keep the original file available for updates throughout the day.
Kind regards
Bernd
Am 18.06.2022 um 20:06 schrieb Charles Mills:
fopen / append
write one record with timestamp and the 24 bytes of collected data
fclose
Are you saying that I will not then end up with 24-byte "physical" blocks, or
did you not consider that part of my original post?
Yes, I agree, if the writer has the file allocated for only a brief period then
some sort of collision logic is manageable.
I would prefer to write it in Rexx but C++ is not out of the question. I hope I have long
since written my last "large" assembler application.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bernd Oppolzer
Sent: Saturday, June 18, 2022 10:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Some UNIX file usage questions
I would use one single normal MVS dataset and make the started task
every 15 minutes do the following:
fopen / append
write one record with timestamp and the 24 bytes of collected data
fclose
this will last only microseconds, and your file can have any desired
blocksize.
(I assume that you are writing the program in C and that you can use the
C runtime system, but if it is ASSEMBLER, it should work as well).
The reporting programs can access the file at any time, with the exception
of the small period of time when the started task is doing the update.
If this makes you feel unsecure, you can make your reporting programs check
how long ago the started task made its last update or so (say: if there is
enough time to complete the report) ... or another sophisticated method
of making sure that there will be no trouble. I didn't think much about
this,
but I'm sure there are several clever methods to synchronize the (one)
writer and the many readers.
For me, it does not make a real difference if the file is a MVS dataset or
a Unix file ... but I must admit, I have not much experience with Unix files
on MVS. It would indeed make a BIG difference, if I had a DB2 database;
then I would not think a second about concurrency.
----------------------------------------------------------------------
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
