Mike, In the days when I managed a number of systems for education purposes, in fact requiring a set of "PARMLIBs" and "PROCLIBs" for each of the courses, I had to come up with a system that reminded me what each of my members was and why it was there.
My solution was to create a member named $$$INDEX in each partitioned data set, library. This typically had one line for each of the members to provide a hint as to why the member was in the library. (In the case of libraries for object modules or programs, a suitable related source library was used to contain the "index" lines.) When I did some extended consultancy work a few years ago, I found I was adding members to and changing members in libraries and, to some extent I was in the same situation you are in - although it didn't occur to me that there might be attempts simultaneously to update a member. Of course, I added the $$$INDEX member to any libraries I created but I also added it to any libraries to which I needed to add a member and I added the name of the person responsible for the member, generally the permanent employee whom I was assisting - or it may have been my name for anything that was related to my experiments and which could be scrapped after I'd gone. By adding $$$INDEX members to libraries I hoped I was giving a strong hint to the customer's folk how to deal with the problem of many people needing to add members to any one library. Implied in this technique is associating a member in a shared library with one person who is then responsible for, "owns", that member. Thus in the case where many people could have an interest in one member, it is required that all requests to make changes go though that one person. This completely avoids your original problem - although some, including yourself possibly, may argue it introduces another one. Another implication of this technique is that it allows a discipline to be imposed on shared libraries - or even a library under sole ownership of someone without perfect recall of everything he/she has done over the past x years where x could extend over a decade or more. There is also a person who is responsible for, "owns", the library. He/she is entitled to remove any member which is not documented as having an "owner". Thus the tendency for libraries to accumulate rubbish may be avoided - which was where I came in with my $$$INDEX member. Incidentally, with my large number of course-related libraries - and non-partitioned data sets, I saw the need for a special hlq.$INDEX data set, where hlq was related to a group of courses, "schools". These data sets performed a similar role of describing. typically in one line, what a particular data set did. Again, if the data set didn't have a description in the $INDEX data set it didn't logically exist and could be erased during a "clean-up" sweep. Also for those of my data sets subject to being "migrated" away, the $INDEX data set was a way of being sure that a particular data set really did exist when I remembered I'd done some work years ago similar to something I now wanted to try again. I dare say there are some products out there which address this sort of problem. I just hope whatever technique they employ isn't too overcomplicated ... Chris Mason ----- Original Message ----- From: "Martin, Mike" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <IBM-MAIN@BAMA.UA.EDU> Sent: Friday, 25 August, 2006 7:31 PM Subject: Serializing changes to parmlib/proclib > All, > > We are beginning to customize our z./OS 1.7 (to replace 1.4). We have > several folks who will be updating parmib and proclib. There is a > possibility that we might step on each other's changes. Say, for > instance, two people are making changes to COMMNDxx. Some people stage > their changes, i.e. copy parms out to another temporary library and work > on them and... then later... copy them back to parmlib. > > My question.... Is there a way to lock member so that only one person > can be working on a member (or members) while they have the lock (the > lock could be held for days at a time)? (Some sort of change control > software comes to mind, but since this is a brand new vanilla test > system, we don't have time to implement that. SCLM also comes to mind, > since it comes with the system, but I don't know if that would work.) > > I know communicating is key, but we are looking for extra controls so we > don't step on each other. Any good ideas for serializing access to > libraries we will be customizing? > > Mike Martin ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
