SHR was primarily designed to allow a max of one writer and any number of readers. When you allow multiple writers, then there is no longer an obvious definition of what is the desired/intended "correct" result when two different processes want to update the same part of that data set, so typically some solution unique to each application would have to be implemented rather than a generic solution.
Depending on your other constraints, it might be simplest for all the jobs to use their own unique data set and then use a sort/merge step to combine the records in the desired order, if they must all be in a single dataset -- or if the order is not significant, just concatenate all the separate data sets together under a single DD to read as if they were a single sequential data set for what ever application needs to read the combined data. Or if you have a job scheduler and these are production jobs that aren't required to run concurrently but just have problems if that happens by accident, most job schedulers have ways to inhibit conflicting jobs from running in parallel, like defining a single resource required by each of the conflicting jobs and which must be free before each job is submitted. That way you avoid having jobs tie up initiators waiting on availability of a data set. I'm sure there are other possibilities, depending on your constraints. Joel C Ewing On 2/24/21 12:57 PM, Joseph Reichman wrote: > You are correct in your assumption of what I am trying to do so what is the > point of share options > > > >> On Feb 24, 2021, at 12:55 PM, Joel C. Ewing <[email protected]> wrote: >> >> But if you are talking about having multiple jobs having the file open >> for writing concurrently, pretty sure you are talking about either using >> VSAM RLS or observing some fairly stringent rules that requires the >> programs involved to manage file record integrity on their own and to >> use a SHR option that allows multiple concurrent opens for write and >> constantly refreshes buffers for each record processed. It's not just >> a matter of substituting a VSAM file for a RECFM=VB file. If you try >> multiple concurrent OPENs for write on a VSAM with the usual default SHR >> options, only the 1st concurrent open for write will succeed. >> >> If the object is to be able to write randomly interspersed records from >> multiple jobs running concurrently, another possibility that might be >> explored is to use a UNIX file and have all the jobs append output to >> the same unix "log" file. >> >> z/OS assumes you want file integrity and deterministic behavior and >> enforces that on MVS data sets. >> The Unix world assumes you want what you "ask" for and if you ask for >> multiple processes to write to the same file concurrently in ways that >> are non-deterministic, it assumes random ordering from concurrent writes >> is acceptable. >> >> Joel C Ewing >> >>> On 2/24/21 11:11 AM, Massimo Biancucci wrote: >>> Joseph, >>> >>> for sure. >>> >>> VSAM variable length is OK. >>> >>> When define VSAM keyword RECORDSIZE( 1000 131072 ) states lrecl from to. >>> >>> Best regards. >>> Max >>> >>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> >>> Mail >>> priva di virus. www.avast.com >>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> >>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >>> >>> Il giorno mer 24 feb 2021 alle ore 17:38 Joseph Reichman < >>> [email protected]> ha scritto: >>> >>>> Hi >>>> >>>> I have multiple jobs sharing the same the same output dataset >>>> >>>> It’s RECFM=VB >>>> >>>> Is it possible to define this RECFM under VSAM, as with VSAM multiple jobs >>>> can write to the same dataset >>>> Thanks >>>> >>>> ... >>>> >>>> -- >>>> Joel C. Ewing >>>> ... -- Joel C. Ewing ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
