First, LIBR is a program, not a proc (VSE defaults to PGM, not PROC, on the EXEC statement). LIBR is a VSE operating system component. LIBR can be used to catalog, for example, an OBJ module in to a VSE library:
// EXEC LIBR,PARM='ACCESS SUBLIB=USER.PROD' CATALOG DDAR04.OBJ REPLACE=YES ...object module goes here... /+ /* /& On the other hand, LNKEDT (the VSE linkage editor) is used to catalog an executable phase (VSE load module) to a VSE library: // JOB LNKEDT // LIBDEF PHASE,CATALOG=USER.PROD // OPTION CATAL PHASE DDAR04,* INCLUDE DDAR04 // EXEC PGM=LNKEDT /& The lines between OPTION CATAL and EXEC LNKEDT are instructions to the linkage editor. This instructs it to create phase named DDAR04 from DDAR04.OBJ found in the system library search chain (something that z/OS does not have). The "LIBDEF PHASE,CATALOG=USER.PROD" JCL statement specifies the destination VSE library name, the the "OPTION CATAL" JCL statement instructs the linkage editor to catalog it's result to that library. Is this the same "product library" as is LIBR? Well, they are both part of VSE. And for all I know (I am not a systems programmer) LIBR could be used "under the covers" by LNKEDT. Anyway, as far as I know, these are the only two methods of placing a member in a VSE library. Even an application program would, I assume, call LIBR or LNKEDT to place something in a VSE library. Seems to me this standard of placing things in a library is a good thing. YMMV. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 5/21/2010 at 7:18 PM, in message <4bf730fe.6050...@ync.net>, Rick Fochtman <rfocht...@ync.net> wrote: > ----------------------------------<snip>--------------------------------- > >>I am not interested in it being in the load module (or program object), > though that may be useful for things other than what I am specifically > concerned about. I am interested in it being in the directory (be it PDS or > PDSE). >> >>Here is my specific concern. If a new module is to be implemented today > (though perhaps bind/linked prior to today and then copied in to the load > library today) I want to be able to verify for sure that it was done. > Sometimes our production migration process has failed in that the actual of > the load module to production was forgotten, or somehow failed, or something. > In VSE I can do this: >> >>// EXEC LIBR >>LISTD SUBLIB=USER.PROD >>/* >> >>And I get a nice report of the members in the USER.PROD VSE library, like > this: >> >>-------------------------------------------------------------------- >>DIRECTORY DISPLAY SUBLIBRARY=USER.PROD DATE: 2010-05-21 >> TIME: 18:41 >>-------------------------------------------------------------------- >> M E M B E R CREATION LAST BYTES LIBR CONT SVA A- R- >>NAME TYPE DATE UPDATE RECORDS BLKS STOR ELIG MODE >>-------------------------------------------------------------------- >>ACCTCHEK PHASE 02-02-20 08-06-04 35984 B 37 YES NO 31 ANY >>ACCTNO PHASE 08-07-31 09-02-26 21080 B 22 YES NO 31 ANY >>ACDSTAT1 PHASE 03-06-13 - - 12344 B 13 YES NO 31 ANY >>ACDSTAT2 PHASE 03-06-13 - - 54064 B 55 YES NO 31 ANY >>ACHCVT PHASE 07-07-25 07-08-28 24688 B 25 YES NO 31 ANY >> >>Is that not very useful? >> >> > --------------------------------------<unsnip>------------------------------------- > Frank, what you're asking for is not unreasonable. Unfortunately, > directory entry data can vary from product and there are no set > standards beyond the first 12 bytes. For example, what product created > the members in this example? Does your LIBR proc use something from the > same "product family" to create this listing? Do all those dates get > appropriately updated when you move the member into USER.PROD? Is that > move done by another piece of this "Product family"? There are just too > many variables to be able to say that "This product or program will give > you a similar or equivalent listing." The high level of flexibility of > z/OS and its predecessors is in part due to this lack of concrete > standards. It's not always helpful for those of us that manage system > resources, etc., but it's part of the evolution, whether we like it or not. > > Rick > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html >>> The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
