I do not agree to Paul's answer. flockfile() only relates to file descriptors. Opening another file descriptor for the same file will not be in scope of that particular lock. Instead you might consider BPX1FCT with the BPXYBRLK mapping structure. However, as found in the "important note" of v_lockctl description in PFS File System Interface Reference, all locking mechanisms are just convention for well-behaving processes and do not guarantee exclusive use.
IMHO, POSIX and common Unix implementations just don't offer exclusive control as found in MVS (i.e. GRS). May be you can use ISGENQ to obtain an enqueue for Unix resources -- but beware of being overconfident. Cheers Michael Von: Elardus Engelbrecht <elardus.engelbre...@sita.co.za> An: IBM-MAIN@bama.ua.edu Datum: 2012-04-19 16:13 Betreff: Re: USS File Integrity Gesendet von: IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> Donald Likens wrote: >I just ran two STCs that updated the same z/OS USS file at the same time. How do I stop multiple processes from updating the same z/OS USS file at the same time? Paul gave you a very good answer, but I wonder how was that USS file allocated in the first place? Dynamic Alloc, JCL DD statement, other method perhaps? Does it (allocation method) matters despite usage of flockfile()? Just curious of course. zMan: I think your father WWII ship is still sailing somewhere ( near that lovesick whale? :-D ) because of the constant disagreement about *true unfathomable* meaning of USS!!! :-D Groete / Greetings Elardus Engelbrecht ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
