Or, you could approach the problem from a different direction. If you're only talking about a couple libraries that are being changed in a few thousand places, you could do dataset aliases to point the old dataset name to the new dataset. I'm not saying it would be the best approach, but it would save you from having to change 3000+ JCL members.
Or you could do a combination of aliases and JCL mass changes to save this from happening in the future. Change all the JCL from (for example) SAS.SAS609.whatever to just SAS.whatever, then set up an alias to point SAS.whatever to SAS.SAS913.whatever. Then when you upgrade to SAS version 10, all that would need to be changed is the alias to now point SAS.whatever to SAS.SAS1002.whatever. Just a thought. Rex -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Jim McAlpine Sent: Thursday, August 19, 2010 10:08 AM To: [email protected] Subject: Re: JCL "Mass Editor" On Thu, Aug 19, 2010 at 3:45 PM, Monty Spivak <[email protected]> wrote: > Hi, > > I am is seeking a JCL "Mass Editor" (basically, multiple file search and > replace in an LPAR). We have 3,000 JCL scripts and are seeking to make > changes to upgrade SAS versions. Would you know of an appropriate tools to > use (I know that someone could write scripts to examine the JCL scripts, but > it would be a lot nicer if one would just be able to use a "search and > conditionally replace" against all of the JCL in an LPAR). > > > > Here is what I already considered and discarded for various reasons: > > 1. ISPF editor, and others, have a search and replace, but it is for only > for 1 script at a time. > > 2. Unload it to a huge sequential file, use ISPF to edit it, and then load > it back into a the PDS. Failing that, JCL is simply stored as clear text in > a PDS (partitioned dataset). Anything that will read a PDS would work, or > use the unload process to get one sequential file first. Our customer would > not like this approach. > > 3. I am sure that there are not one or two procs somewhere where the change > could be made. Most shops have procs that control the calls to SAS and other > such products. The idea is to bury all the installation specific stuff in > one proc, then have the user jobs call the proc. That way when you change > something, you only change it in the one proc, not every user job. It > appears that the JCL was not originally structured this way... > > I would appreciate if someone would point me in the right direction... > > Thanks, Monty > > Monty Spivak > SAS Institute Canada > [email protected]mailto:[email protected] > > Filemanager from IBM will allow find/change in every member of a PDS if that is what you are after. Jim McAlpine ---------------------------------------------------------------------- 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 The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. ---------------------------------------------------------------------- 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
