Re: Serializing changes to parmlib/proclib
If you don't have time to do it right, when will you have time to do it over? I like the 'parmlib nazi' approach. Simple, effective, approved by auditors. Make all changes via request rather than direct update. A skilled human makes a better change control system anyway. My $0.02 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Martin, Mike Sent: Friday, August 25, 2006 12:32 PM To: IBM-MAIN@BAMA.UA.EDU 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 Mike Martin NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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
Re: Serializing changes to parmlib/proclib
In [EMAIL PROTECTED], on 08/25/2006 at 01:31 PM, Martin, Mike [EMAIL PROTECTED] said: 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? LMF or SCLM? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Serializing changes to parmlib/proclib
In [EMAIL PROTECTED], on 08/27/2006 at 11:28 AM, Paul Gilmartin [EMAIL PROTECTED] said: ISPF/LMF. Keep a source copy of each library and a production copy. Make all changes to the source copy with ISPF Edit, which serializes updates to members. Periodically (e.g. daily plus on special request) copy the entire library, or only all members modified since the last refresh, to the production copy. NO! Do the move *only* after testing. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Serializing changes to parmlib/proclib
In [EMAIL PROTECTED], on 08/27/2006 at 05:17 PM, Paul Gilmartin [EMAIL PROTECTED] said: Likewise, if an edit session is interrupted with RECOVERY ON, does ISPF lock out other editing of the same member until the original user recovers? No. As others have noted here, CMS UPDATE provides mechanisms for managing delta libraries far more sophisticated than IEBUPDTE. I exploited them; they were useful, but not sufficient to make me prefer CMS nowadays to z/OS. While I don't prefer CMS to TSO, I *do* prefer XEDIT to TSO EDIT and miss it even when using ISPF/PDF EDIT. I wonder how hard it would be to port THE to TSO? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Serializing changes to parmlib/proclib
In a recent note, Shmuel Metz (Seymour J.) said: Date: Mon, 28 Aug 2006 08:48:46 -0300 In [EMAIL PROTECTED], on 08/27/2006 at 05:17 PM, Paul Gilmartin [EMAIL PROTECTED] said: Likewise, if an edit session is interrupted with RECOVERY ON, does ISPF lock out other editing of the same member until the original user recovers? No. Ouch! Feels like a significant flaw in the RECOVER protocol. While I don't prefer CMS to TSO, I *do* prefer XEDIT to TSO EDIT and miss it even when using ISPF/PDF EDIT. I wonder how hard it would be to port THE to TSO? CMS ISPF supports using either PDF or XEDIT. (This violates the nice numbers rule: There are just three nice numbers -- zero, one, and as many as you want.) If CMS ISPF provides for a choice of editors, the set should be extensible by the user. Likewise TSO. When CMS ISPF uses XEDIT, it postprocesses the edited member in order to update member statistics. Something similar would be needed if ISPF provided a choice of editors under TSO. How does WSA deal with the need to update statistics? Could you run THE on a workstation with TSO? BTW, of course I agree with your correction concerning testing before installation in production. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Serializing changes to parmlib/proclib
From: Paul Gilmartin [EMAIL PROTECTED] How does WSA deal with the need to update statistics? Could you run THE on a workstation with TSO? WSA has an option that allows member statistics to be generated (or not) when files are transferred to a mainframe. I don't know if THE works with TSO, but it can certainly be invoked from an ISPF session. Dave Salt SimpList(tm) - The easiest, most powerful way to surf a mainframe! http://www.mackinney.com/products/SIM/simplist.htm -- 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
Re: Serializing changes to parmlib/proclib
In [EMAIL PROTECTED], on 08/28/2006 at 08:52 AM, Paul Gilmartin [EMAIL PROTECTED] said: CMS ISPF supports using either PDF or XEDIT. (This violates the nice numbers rule: There are just three nice numbers -- zero, one, and as many as you want.) It would be no big deal to plug additional TSO editors into ISPF; the issue is porting THE or XEDIT to TSO in the first place. How does WSA deal with the need to update statistics? I'm not aware of any support for statistics unless you use the ISPF/PDF editor. Could you run THE on a workstation with TSO? ? I don't know what you mean by run THE on a workstation with TSO. You can run THE on a workstation and use it via the WSA. You can run TSO on the workstation if you have Hercules. Those are two unrelated environments. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Serializing changes to parmlib/proclib
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. At my last job, I was the parmlib nazi. All changes to parmlib went to me (except off hours to fix a problem). IMHO, there should only be one person updating the parmlib. You always want the system to IPL. For example for Audits, there was only one person making changes to the APF list. Regardless of if it's one person or many updating the parmlib, I would recommend using a parmlib concatenation. See what I did here: http://www.planetmvs.com/userexperiences/os390r6.html#parmlib Put the new parmlib dataset that contains all changes just for the new operating system in front of your current concatenation. All of the changes go there instead of your production libraries so you never cause a problem to your current system. I don't know if its on that web page but I also create a system symbol like OSLEVEL with the value like ZOS17. There would be a LNKLST library with a name like SYS2.OSLEVEL..LINKLIB for modules that are needed just for the new operating system. One place I worked had a third SYSRES, SYSR3, which was for program products and had the updated libraries to match that level of the operating system. That makes it nice to bring in everything needed for that level of the OS. -- 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
Re: Serializing changes to parmlib/proclib
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
Re: Serializing changes to parmlib/proclib
In a recent note, Chris Mason said: Date: Sun, 27 Aug 2006 19:06:36 +0200 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 ... ISPF/LMF. Keep a source copy of each library and a production copy. Make all changes to the source copy with ISPF Edit, which serializes updates to members. Periodically (e.g. daily plus on special request) copy the entire library, or only all members modified since the last refresh, to the production copy. Use RACF rules to restrict the class of individuals authorized to update the production copy. Use an intermediate level library for review and approval of changes identified by SuperC. Does ISPF LM have a filter that will select all members modified since a given point in time, for generation of IEBCOPY SELECT statements? -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Serializing changes to parmlib/proclib
From: Paul Gilmartin [EMAIL PROTECTED] Does ISPF LM have a filter that will select all members modified since a given point in time, for generation of IEBCOPY SELECT statements? Copying all members that were modified since a given point in time is extremely easy to accomplish if SimpList is installed. First, SEE would be entered on the member list command line to display a panel where the types of members you want to SEE can be defined. For example, a load library could be filtered to SEE only those members that had specific attributes such as RENT, REUSE, AMODE(31) etc. Data sets with fixed and variable length records can be filtered based on things like size, date created, date modified, and so on. After entering SEE on the member list command line, the panel shown at the following image would be displayed: http://www.mackinney.com/products/SIM/simplistSCR7.htm This panel allows member lists to be filtered based on any ISPF statistics, such as members that were changed on, before, during, or after a specified date. When the resulting member list is displayed (i.e. a list containing only those members that match the specified criteria), 'C *' could then be entered on the command line to copy every member displayed in the list. Personally, instead of copying modified members to another data set I prefer to back them up to a directory on my PC. So, I use the SEE command to see only the members I've changed since a certain date, and then I enter 'N *' on the command line to tra'N'sfer all of the displayed members to my PC. Dave Salt http://www.mackinney.com/products/SIM/simplist.htm SimpList - the easiest, most powerful way to surf a mainframe! -- 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
Re: Serializing changes to parmlib/proclib
On Aug 27, 2006, at 10:48 AM, David Alcock wrote: ---SNIP- At my last job, I was the parmlib nazi. All changes to parmlib went to me (except off hours to fix a problem). IMHO, there should only be one person updating the parmlib. You always want the system to IPL. For example for Audits, there was only one person making changes to the APF list. Regardless of if it's one person or many updating the parmlib, I would recommend using a parmlib concatenation. See what I did here: http://www.planetmvs.com/userexperiences/os390r6.html#parmlib --SNIP--'' Dave, \ Good suggestions. At my last job they had a really convoluted way of do it which consisted of using the last two characters of the member name. I won't even describe it as the limit on here is 100 lines. I have followed this thread as it shows other ways of doing a seemingly simple job. Thanks to all the have contributed. I have learned something. Ed -- 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
Re: Serializing changes to parmlib/proclib
On Sun, 27 Aug 2006 19:00:26 +, Dave Salt [EMAIL PROTECTED] wrote: Copying all members that were modified since a given point in time is extremely easy to accomplish if SimpList is installed. First, SEE would be Promo noted. Likely valuable to those who have the product or are considering obtaining it. Personally, instead of copying modified members to another data set I prefer to back them up to a directory on my PC. So, I use the SEE command to see only the members I've changed since a certain date, and then I enter 'N *' on the command line to tra'N'sfer all of the displayed members to my PC. Does this satisfy the OP's requirement to serialize updates among multiple developers? And once you've moved the recent members to your PC, how do you transfer them to PARMLIB/PROCLIB? Workstation Agent might allow a programmer a prolonged virtual edit session, even extending through a time when the workstation is disconnected from the mainframe, perhaps in a briefcase in transit from one workplace to another. Does ISPF maintain the serialization of the member being edited over such intervals? Likewise, if an edit session is interrupted with RECOVERY ON, does ISPF lock out other editing of the same member until the original user recovers? I once participated in a group freeware development project on CMS. The team leader accepted updates in CMS UPDATE (similar to IEBUPDTE) format; checked for collisions; and redistributed them to the team. I generated my deltas with SuperC; others may have used XEDIT or other techniques. Of course, any developer must be careful to generate the delta relative to a snapshot at the time he began his modifications, not relative to the current distribution, which would cause regressions. As others have noted here, CMS UPDATE provides mechanisms for managing delta libraries far more sophisticated than IEBUPDTE. I exploited them; they were useful, but not sufficient to make me prefer CMS nowadays to z/OS. That tipping point happened about TSO/E Rel 2, when Rexx came to MVS. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Serializing changes to parmlib/proclib
That tipping point happened about TSO/E Rel 2, when Rexx came to MVS. ESA/3.1.3oE. On, or about, 1990. I was told by my manager to stick with CLIST because REXX was 'too' expensive. But, as I still believe, productivity is more important. Also, the only LRECL allowed was 80, under EXECIO, back then. When in doubt. PANIC!! -- 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
Re: Serializing changes to parmlib/proclib
- Original Message -
From: Chris Mason [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@BAMA.UA.EDU
Sent: Sunday, August 27, 2006 1:06 PM
Subject: Re: Serializing changes to parmlib/proclib
snippage
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 ...
Mackinney's SimpList offers a very uncomplicated solution to this problem.
I simply enter comments next to the objects I work with. If you click the
link below you'll see an example of what I mean:
http://www.mackinney.com/products/SIM/simplistSCR1.htm
(Sorry, but I don't have access to my system at the moment, so I cannot
show you any of my actual examples, but this image from the vendor's website
illustrates the point)
I tend to use much more descriptive comments than those shown on the sample
screen. For example, I might do something like this:
OBJ 1 === 'PI00.PROD.JCLLIB(BKWJR1)'{WEEKLY BACKUP JOB
OBJ 2 === -P2PROD.CST_OS_TDB {DB2 TABLE OF OVERSEAS
CUSTOMERS
If a longer comment is required I usually enter it above the object as in
this example:
OBJ 3 === {THE FOLLOWING JOB SHOULD ONLY BE SUBMITTED ON FRIDAYS:
OBJ 4 === 'PI00.PROD.JCLLIB(BKFJR2)'
Another nice thing about entering comments is that I can use them to find
objects whose names I've forgotten. For example, I could enter the following
on any ISPF command line:
=== SL FIND WEEKLY
The 'SL' launches SimpList and 'FIND WEEKLY' searches through all my object
lists until 'WEEKLY' is found. It then opens the list and positions me to
the object name so I can select it if I want.
If I'm already in a SimpList session I don't need to enter 'SL', i.e. I
could just enter 'FIND WEEKLY'. To see this in action, take a look at the
following image where a FIND command has been entered on object list 'B'
(i.e. a personalized list of BookManager bookshelves), and the string being
searched for is found on list 'M':
http://www.mackinney.com/products/SIM/simplistSCR14.htm
Middle age has much to recommend it; the kids are (almost) grown, mortgage
is (almost) paid off, but my memory seems to be getting more sieve-like with
every passing year. There is no way I could possibly remember all the names
of
the objects I work with, never mind what each object contains. So for me,
the ability to enter comments and use them as a way to search through all my
object lists is invaluable. It also avoids the potential problem you
mentioned where an $$$INDEX data set or member might be deleted. Is this the
'simple' solution you were looking for?;-)
Don Leahy
--
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
Re: Serializing changes to parmlib/proclib
In a recent note, Ted MacNEIL said: Date: Sun, 27 Aug 2006 22:23:47 + That tipping point happened about TSO/E Rel 2, when Rexx came to MVS. ESA/3.1.3oE. On, or about, 1990. Feels about right. I stayed with CMS from inertia for many years after that. I seldom look back, other than when Shmuel raises a point of nostalgia. I was told by my manager to stick with CLIST because REXX was 'too' expensive. I thought it was bundled with TSO/E. Or was he thinking performance? or the cost of technolgy transition? I had a colleague who clung to EXEC2 on CMS because he thought it outperformed Rexx. The residual technical advantage of CMS EXEC (not EXEC2) and CLIST alike is they can enter modal dialogs with their respective editors, where Rexx can not. Opportunity for enhancement. But, as I still believe, productivity is more important. Never could understand CLIST, either. Couldn't wrap my mind around STR. Rexx was easier. Also, the only LRECL allowed was 80, under EXECIO, back then. Must have been way early; I never knew that. It got better quickly In fact, I remember an early transitional TSO Rexx GIM/Guide/whatever that recommended coding Rexx using mixed case for legibility (sorry, Ted and Shane), and making SYSEXEC RECFM=VB to minimize the need for statement continuation. Feels like the influence of MFC. I can no longer find any evidence of that manual. IBM distributes Rexx EXECs generally Fixed 80. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Serializing changes to parmlib/proclib
recommended coding Rexx using mixed case for legibility (sorry, Ted and Shane) I don't know why you are appologising to me. I always use mixed case in REXX. But, I don't code: If expression Then Do Statement(s) End When in doubt. PANIC!! -- 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
Re: Serializing changes to parmlib/proclib
There is the KISS system. When you check out a member, replace it with a template that says something like in block letters checked out by Then the member is checked out and they should not change. I know it requires agreement among the people but it is simple and free. Brad Taylor -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Martin, Mike Sent: Friday, August 25, 2006 12:32 PM To: IBM-MAIN@BAMA.UA.EDU 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
Re: Serializing changes to parmlib/proclib
From: Martin, Mike [EMAIL PROTECTED] We have several folks who will be updating parmib and proclib. There is a possibility that we might step on each other's changes. 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 As you know, a water-tight solution requires the use of a change control product such as Endevor or SCLM (etc). Failing that, one thing that can help is to use merged member lists. For example, enforce a rule that all updates to procs must be performed in a data set called 'UPDATES.PROCLIB'. If the data set is merged with 'SYS1.PROCLIB', the merged member list will show at a glance which procs are being worked on (i.e. exist in Lib 1) and which are not being worked on (i.e. exist in Lib 2). If a proc exists in Lib 2, simply selecting it for edit will 'lock it' for the length of the edit session. If the member is saved, the member will automatically be copied to and saved in Lib 1, while the member in Lib 2 will NOT be updated. HTH, Dave Salt SimpList(tm) - The easiest, most powerful way to surf a mainframe! http://www.mackinney.com/products/SIM/simplist.htm -- 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
Re: Serializing changes to parmlib/proclib
At 18:12 + on 08/25/2006, Dave Salt wrote about Re: Serializing changes to parmlib/proclib: If a proc exists in Lib 2, simply selecting it for edit will 'lock it' for the length of the edit session While there is a lock, it is on the wrong RNAME. ISPF uses a QNAME of SYSEDIT (I think) and a RNAME of DSN+Member-Name NOT the accurate RNAME of DSN+VOLSER+Member-Name. IOW: Editing DSN(X) on RES170 will lockout an attempt to edit DSN(X) on RES140. This is due to the use of SYSDSN RNAME rules for SYSEDIT even though at the time of the ENQ the VOLSER of the dataset is known (unlike SYSDSN when it is usually not known at ENQ time). -- 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
