Hard-Coded Library List Woes

Hey, Ted:

We have CL programs that execute the Add Library List Entry (ADDLIBLE) and Remove Library List Entry (RMVLIBLE) commands because a needed library is not in the library list at runtime. I know this sort of thing should be avoided, but permanently adding the needed libraries to the library list would cause other problems. Because they modify the library list, these programs are impossible to test. Do you have any advice?

--Dan

Adding a library list entry at runtime is a bad, but common, practice. Don't expect me to fuss at you, Dan. Ideally we should be able to define adequate library lists in job descriptions and never have to use the ADDLIBLE and RMVLIBLE commands in production code. However, this is not an ideal world.

As you point out, these programs are impossible to test, because they modify the library list that you've set up for testing purposes. It's no good to place a test file in a test library, only to have the ADDLIBLE command place a production file at the top of the library list.

I suggest you replace the ADDLIBLE and RMVLIBLE commands with calls to two CL programs. Here is one possible production version of the programs:

/* Program ADDLIBLE */
pgm (&lib &position)                 
                                     
   dcl &lib       *char 10           
   dcl &position  *char  6           
                                     
   addlible &lib &position           
   monmsg cpf0000 exec(do)           
      sndpgmmsg msgid(cpf2118) +     
         msgf(qcpfmsg) msgdta(&lib) +
         msgtype(*escape)            
   enddo                             
                                     
endpgm                               

Here is another possible version:

/* Program RMVLIBLE */
pgm (&lib)                
                          
   dcl &lib       *char 10
                          
   rmvlible &lib          
   monmsg cpf0000         
                          
endpgm                    

I've given these examples the same names as the CL commands they replace. You may prefer to give them other names.

Place these programs in a general utility library that is not in the system portion of the library list. For many shops, QGPL would be a good choice.

Replace the ADDLIBLE and RMVLIBLE commands in your programs with calls to these programs:

/* ADDLIBLE   LIB(MYLIB) POSITION(*LAST) */   
   CALL       PGM(ADDLIBLE) PARM(MYLIB *LAST) 
                                               
/* RMVLIBLE   LIB(MYLIB) */                   
   CALL       PGM(RMVLIBLE) PARM(MYLIB)       

You'll also need to create other versions of the ADDLIBLE and RMVLIBLE programs for testing purposes. The test versions do not alter the library list.

Here is a possibility for the test version of the ADDLIBLE program:

pgm (&lib &position)      
                          
   dcl &lib       *char 10
   dcl &position  *char  6
                          
   return                 
                          
endpgm                    

Here is another:

pgm (&lib &position)                                      
                                                          
   dcl &lib       *char 10                                
   dcl &position  *char  6                                
   dcl &user      *char 10                                
                                                          
   rtvjoba  user(&user)                                   
   sndmsg ('Test version of ADDLIBLE is running.' *bcat + 
           'Lib:' *bcat &lib *bcat +                      
           'Pos:' *bcat &position) +                      
          tousr(&user)                                    
   return                                                 
                                                          
endpgm                                                    

When you want to test a program that modifies the library list, be sure the library that contains the test versions of the ADDLIBLE and RMVLIBLE programs precedes the library that contains production versions.

As with all code you get from Midrange Guru, or any source from outside of your shop, test everything thoroughly and use at your own risk.

Qualification of objects is in general a bad idea. I encourage you to look for ways to eliminate hard-coded library names.

--Ted

Sponsored By COMMON

COMMON Fall 2003 Conference and Expo IT in the Palm of Your Hand September 7 - 11, in Orlando, Florida. · Education: Hundreds of sessions over five days · Networking: Meet IT professionals, IBM executives, and developers · Influence IBM: Attend sound-off sessions · First-Hand Look at Latest Products: Talk to the industry's top solution providers COMMON is the best value in IT education, so don't miss out! Click and visit www.common.org for details!