Library List Tinkering

[daly.michael@verizon.net]

On Monday, February 08, 1999, 01:39 PM, Mark Wheeler wrote: Apologies, but I found your email somewhat incoherent. I hope this provides what you asked for. The library list of any given job starts with the QSYSLIBL and QUSRLIBL entries. The QUSRLIBL entries can be overridden by the entries in the JOBD of the job. JOBD entries replace, as opposed to supplement, the values provided by QUSRLIBL. The CURLIB is provided by the user profile used by the job. If CRTDFT is specified then commands that use the CURLIB parameter look to QGPL. After the job is active you can change the CURLIB value with the CHGCURLIB command, add to the user portion, or remove, with the ADDLIBLE and RMVLIBLE commands, respectively, and add, or remove, entries in the system portion of the LIBL with the CHGSYSLIBL command. This is not a comprehensive listing of how to manipulate the library list of any given job. My focus is manipulating the library list with a CLP, where all of the commands mentioned are effective. One more tip: To manipulate to library list for an interactive job, use the EDTLIBL command. <hr> <a > href="http://www.freshpoint.com"><imgsrc="http://www.freshpoint.com/graphics/f ooterlogo.GIF"border="0" width="162" height="48"> </a><font > color="#408080">Michael Daly, Sr. P/A FreshPoint, Inc. (972) 392-8169 </font></

[T.Holt]

I try to never say "never", but one rule I follow religiously is not to let a program change the library list. I've seen too many problems come of it, and there have been times I couldn't test a program because of it. If possible, let job descriptions control the library list. It seems a lot of programmers don't know how to create a job description. I've seen systems with one job description that everybody uses. If a programmer is trying to get a program to run, and it can't find a file, they either add an override to the qualified file name or code an ADDLIBLE command. Sometimes they get away with this, and sometimes they wind up updating a production file during testing. Sometimes it's impractical for job descriptions to control the library list. In such cases, I've used other soft-coding solutions, like storing the library list in a file & retrieving it from there as required. This works OK, since I can duplicate the file and let the library list control which copy gets read. When I moved from the S/36 to S/38, one of the first features of the new machine I fell in love with was the library list. I'd wished many times on the S/36 to be able to have both test & production versions of a file on disk at the same time. (Date-differentiated files wasn't sufficient for that.) It almost hurts to look at some of the code I've seen that doesn't use the library list to advantage.

[J.Pluta]

<font color=blue>On Thursday, February 11, 1999, 05:39 AM, Ted Holt wrote: I try to never say "never", but one rule I follow religiously is not to let a program change the library list. I've seen too many problems come of it, and there have been times I couldn't test a program because of it. </font><hr> On the other hand, if you absolutely, positively HAVE to change the library list (for example, Nexgen's Y2K tool, Focus/2000, has to change library lists all the time in order to handle the clients various compile environments), it is easy to write a simple program that doesn't seton LR that will "PUSH" and "POP" the current library list onto and off of a "stack". Prior to changing the library list, you call this program with the "PUSH" opcode; it retrieves the current library list and stores it in an array. After processing, a call with opcode "POP" restores the library list to its previous setting. Multiple PUSHes can be followed by multiple POPs, thereby keeping your library list in sync at all times. Used in concert with the never-ending program registry I've mentioned before in these fora, a library list manager makes it relatively painless to keep your environment clean. (I guess activation groups can be used to clean up never-ending programs as well; I'm not as conversant there as I'd like to be.) Joe

[T.Holt]

You're talking about systems programming, not applications programming. I agree with you.<hr> <font color=blue>On Thursday, February 11, 1999, 07:23 AM, Joe Pluta wrote: On the other hand, if you absolutely, positively HAVE to change the library list (for example, Nexgen's Y2K tool, Focus/2000, has to change library lists all the time in order to handle the clients various compile environments), it is easy to write a simple program that doesn't seton LR that will "PUSH" and "POP" the current library list onto and off of a "stack". </font>

[J.Pluta]

<font color=green>On Thursday, February 11, 1999, 07:37 AM, Ted Holt wrote: You're talking about systems programming, not applications programming. I agree with you. <hr></font> Yeah, I guess you can draw a distinct line in the sand there. We just spent three days tracking anomalies because a client had liberally made use of changing library lists in their production code, which made it almost impossible to create a test version. Even worse, the library list change was imbedded deeply in the BATCH jobstream. It was truly a maintenance nightmare. "I KNOW I made the changes, I KNOW it! Why don't they show up in the debugger?" Joe

[Guest.Visitor]

I agree. Explicitly referencing particular library names can create a maintenance and/or system management nightmare. The rule of thumb I try and follow is that that the only acceptable explicit library reference made in application code is to QTEMP. Otherwise the current library list is always used. If you ever need to reference a particular library there are various softcoding approaches that work well. Best one I've seen is to use a little utility pgm whoose job is to take an "abstract library name" and return an "actual library name". The actual library name returned is then what is used at runtime. Within such a utility the mapping of one to the other can be achieved via table lookups, as Ted suggests, or with any number of other techniques. Derek <font color="#0000CC">On Thursday, February 11, 1999, 05:39 AM, Ted Holt wrote: I try to never say "never", but one rule I follow religiously is not to let a program change the library list. I've seen too many problems come of it, and there have been times I couldn't test a program because of it. If possible, let job descriptions control the library list. It seems a lot of programmers don't know how to create a job description. I've seen systems with one job description that everybody uses. If a programmer is trying to get a program to run, and it can't find a file, they either add an override to the qualified file name or code an ADDLIBLE command. Sometimes they get away with this, and sometimes they wind up updating a production file during testing. Sometimes it's impractical for job descriptions to control the library list. In such cases, I've used other soft-coding solutions, like storing the library list in a file & retrieving it from there as required. This works OK, since I can duplicate the file and let the library list control which copy gets read. When I moved from the S/36 to S/38, one of the first features of the new machine I fell in love with was the library list. I'd wished many times on the S/36 to be able to have both test & production versions of a file on disk at the same time. (Date-differentiated files wasn't sufficient for that.) It almost hurts to look at some of the code I've seen that doesn't use the library list to advantage. </font>

[T.Holt]

Oops, I forgot about QTEMP. I qualify with QTEMP a lot.<HR> <font > color=blue>On Thursday, February 11, 1999, 02:49 PM, Derek Butland wrote: The rule of thumb I try and follow is that that the only acceptable explicit library reference made in application code is to QTEMP. Otherwise the current library list is always used. </font>