Re: Getting BIND/LINK date out of load module members
I thought I'd try good ole AMBLIST and see if it would help. It promptly choked to death on a PDSE Object!!! Then I suggest that you contact IBM service once you have satisfied yourself that it is not a user error. choked to death is not a very technical description. AMBLIST supports Program Objects in PDSEs. Peter Relson z/OS Core Technology Design -- 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
Re: Getting BIND/LINK date out of load module members
Probably qualifies as descriptive though. And more socially acceptable than a few others I've heard. Shane ... On Mon, May 24th, 2010 at 9:56 PM, Peter Relson wrote: ... choked to death is not a very technical description. -- 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
Re: Getting BIND/LINK date out of load module members
On Mon, 24 May 2010 22:26:53 +1000, Shane Ginnane ibm- m...@tpg.com.au wrote: Probably qualifies as descriptive though. And more socially acceptable than a few others I've heard. Shane ... On Mon, May 24th, 2010 at 9:56 PM, Peter Relson wrote: ... choked to death is not a very technical description. If we all had a nickel for each time we heard the term It doesn't work. Still Friday? :) -- 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
Re: Getting BIND/LINK date out of load module members
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Peter Relson Sent: Monday, May 24, 2010 6:57 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Getting BIND/LINK date out of load module members I thought I'd try good ole AMBLIST and see if it would help. It promptly choked to death on a PDSE Object!!! Then I suggest that you contact IBM service once you have satisfied yourself that it is not a user error. choked to death is not a very technical description. AMBLIST supports Program Objects in PDSEs. SNIPPAGE I hate it when I go to recreate something and things work right. I'm going to guess that the update to the load lib (PDSE) I was pointing to started early and we collided. I say that because the output of the AMBLIST appears to give what was being requested. I think a REXX to reprocess the output could give a format similar to LIBR. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer(s) -- -- 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
Re: Getting BIND/LINK date out of load module members
In 4bf7df8b.6f0f.008...@efirstbank.com, on 05/22/2010 at 01:42 PM, Frank Swarbrick frank.swarbr...@efirstbank.com said: Anyway, as far as I know, these are the only two methods of placing a member in a VSE library. Don't they apply only to a CIL? -- 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Getting BIND/LINK date out of load module members
In 4bf6d4bc.6f0f.008...@efirstbank.com, on 05/21/2010 at 06:44 PM, Frank Swarbrick frank.swarbr...@efirstbank.com said: 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. Then you have not accurately described what you are concerned about. It is a cardinal error to confuse a suggested implementation with a requirement. I am interested in it being in the directory (be it PDS or PDSE). How would you do it without breaking existing code? What requirement generates that interest. 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. The data don't need to be in the directory in order to satisfy that concern. In VSE I can do this: // EXEC LIBR LISTD SUBLIB=USER.PROD Is your concern that you have an equivalent report in z/OS? That wouldn't require that those data be in the directory. Is that not very useful? Perhaps, but what makes you believe that you can't create such reports with the existing directory and program structure? -- 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Getting BIND/LINK date out of load module members
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Friday, May 21, 2010 7:44 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Getting BIND/LINK date out of load module members SNIPPAGE 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 DISPLAYSUBLIBRARY=USER.PROD DATE: 2010-05-21 TIME: 18:41 M E M B E R CREATION LAST BYTESLIBR CONT SVA A- R- NAME TYPE DATE UPDATE RECORDS BLKS STOR ELIG MODE ACCTCHEK PHASE02-02-20 08-06-04 35984 B 37 YES NO 31 ANY SNIPPAGE I thought I'd try good ole AMBLIST and see if it would help. It promptly choked to death on a PDSE Object!!! I do miss some of the functions that DOS/VS VSE had/has when I get into some of the brain damaged problems of MVS. I seemed to remember a utility in the MVS world that kinda approximated what you are after, but since it wasn't AMBLIST, I don't know what to suggest, other than to check the CBT and see if there is anything on it that might meet your needs in this area. Regards, Steve Thompson -- Opinions expressed by this poster are those of poster and not necessarily those of poster's employer -- -- 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
Re: Getting BIND/LINK date out of load module members
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 DISPLAYSUBLIBRARY=USER.PROD DATE: 2010-05-21 TIME: 18:41 M E M B E R CREATION LAST BYTESLIBR CONT SVA A- R- NAME TYPE DATE UPDATE RECORDS BLKS STOR ELIG MODE ACCTCHEK PHASE02-02-20 08-06-04 35984 B 37 YES NO 31 ANY ACCTNO PHASE08-07-31 09-02-26 21080 B 22 YES NO 31 ANY ACDSTAT1 PHASE03-06-13 - -12344 B 13 YES NO 31 ANY ACDSTAT2 PHASE03-06-13 - -54064 B 55 YES NO 31 ANY ACHCVT PHASE07-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
Re: Getting BIND/LINK date out of load module members
In 4bf49653.6f0f.008...@efirstbank.com, on 05/20/2010 at 01:53 AM, Frank Swarbrick frank.swarbr...@efirstbank.com said: I find it perplexing, though, that there is apparently no field in a load module PDS that indicates when a member was created and/or last updated. What are IDRDATA, chopped liver? Why is it there for non-load module PDSs It isn't. Not all members are created by ISPF. but not for load module PDSs? It's been in load modules for around 4 decades. In fact, I believe that IDRDATA is older than SPF. Anyone have the exact dates? -- 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Getting BIND/LINK date out of load module members
In 9118ef7037e140479786802e36812d7504b45...@syssrv35.ad.ilstu.edu, on 05/19/2010 at 02:45 PM, Davis, Kriss kpda...@ilstu.edu said: I am working on process to monitor/audit load libraries for new/replaced members during a date range. I have a working version that uses AMBLIST with a SYSIN of LISTIDR. I hope that they've improved the code since the last time that I had to deal with it. The CBT is full of programs for extracting IDR data. I wouldn't be surprised if every single one of them was faster than AMBLIST. Or take Roland's suggestion and use IEWBIND. -- 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Getting BIND/LINK date out of load module members
Frank Swarbrick wrote: On 5/20/2010 at 2:22 AM, in message 29s9v5lniuvtpalf97r7chtu7ogfmj7...@4ax.com, Binyamin Dissen bdis...@dissensoftware.com wrote: snippage Submit a requirement. No doubt. I'm just amazed that such a requirement wasn't submited 30 years ago. Frank 30 years ago IBM would have said (and IIRC did say) that those sort of timestamps are kept for the file, as other OSes keep such things for their files. (Granted, MVS keeps a reference data instead of a modification date.) Further, PDS members are not files, but parts of a file (physical files being called data sets in MVS parlance). If you want those sorts of timestamps kept in the file's data content, then make your application write such data when loading data into such a file. As has been stated, the linkage editor - program binder, and ISPF are two such applications which which write timestamps within the content of data written to their output files. Cheers, Greg -- 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
Re: Getting BIND/LINK date out of load module members
-snip--- And until you explained this, I had believed that the Operating System as a whole existed as a convenience for us humans; not, as you appear to believe, merely to satisfy its own needs. unsnip-- The Operating System IS a convenience to us humans. But if you're using it to run a business, do you really care about the intricate details of how it works? As long as it, with whatever application programs you develop, serve the business needs? And help grow the business? Granted, the original design might be considered flawed today, but nobody 46 years ago could have predicted how the system, and its add-on components, would grow. After all, humans have had millions of years to develop and evolve, but we still have that pesky appendix. ---snip--- As for clutter, better to do such things consistently, in DFSMS for example, rather than haphazardly in ISPF, NFS server, and whatever other services feel obliged to simulate ISPF's facility. unsnip I could offer the trite answer That's the way it's always been done. but that would be completely unsatisfactory. I suspect (but can't prove) that each design team set its own standards, formats, etc. and stuck to them through the evolution of the various products. If you'll recall, the TSO EDITOR didn't add time or date information to the directory entry, until a few enterprising experimenters and developers decided that this might be a good idea. IIRC, SPF didn't show up until somewhere in MVS Release 3. Various other editors, of non-IBM source, were around before then, like ROSCOE and WILBUR and there was even an editor tool for CICS and they all used varying directory entry formats. Even DFSMSdfp doesn't speak for an exact format for a complete directory entry; it only requires the same information as OS/360, in the same format. Some of the DFP-related products use the user area of the directory entry for dates, etc. but the basic entry is the same: 8-byte name, 3-byte TTR and 1 byte of length/flag information. At this point, and indeed for many years, it's not been cost effective to try and standardize all the information stored in a PDS directory entry beyond the basic data. And MANY non-IBM products have specific uses for the user area of that entry, and specific formats. If you were a software vendor, how would you like to tell your customers that all PDS's related to this product must be recreated because we're changing the directory entry format? Or would you like to try to create a utility that would reformat all PDS directory entries' user data field to a common format? Then have the new kid on the block create a new format, for what may be perfectly valid reasons? These are the conditions that prevail. We don't have to like it, but we sure as H*** have to live with it. 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
Re: Getting BIND/LINK date out of load module members
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 DISPLAYSUBLIBRARY=USER.PROD DATE: 2010-05-21 TIME: 18:41 M E M B E R CREATION LAST BYTESLIBR CONT SVA A- R- NAME TYPE DATE UPDATE RECORDS BLKS STOR ELIG MODE ACCTCHEK PHASE02-02-20 08-06-04 35984 B 37 YES NO 31 ANY ACCTNO PHASE08-07-31 09-02-26 21080 B 22 YES NO 31 ANY ACDSTAT1 PHASE03-06-13 - -12344 B 13 YES NO 31 ANY ACDSTAT2 PHASE03-06-13 - -54064 B 55 YES NO 31 ANY ACHCVT PHASE07-07-25 07-08-28 24688 B 25 YES NO 31 ANY Is that not very useful? Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 5/21/2010 at 4:03 AM, in message 2010052948.538d8f58...@smtp.patriot.net, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 4bf49653.6f0f.008...@efirstbank.com, on 05/20/2010 at 01:53 AM, Frank Swarbrick frank.swarbr...@efirstbank.com said: I find it perplexing, though, that there is apparently no field in a load module PDS that indicates when a member was created and/or last updated. What are IDRDATA, chopped liver? Why is it there for non-load module PDSs It isn't. Not all members are created by ISPF. but not for load module PDSs? It's been in load modules for around 4 decades. In fact, I believe that IDRDATA is older than SPF. Anyone have the exact dates? 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
Re: Getting BIND/LINK date out of load module members
--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 DISPLAYSUBLIBRARY=USER.PROD DATE: 2010-05-21 TIME: 18:41 M E M B E R CREATION LAST BYTESLIBR CONT SVA A- R- NAME TYPE DATE UPDATE RECORDS BLKS STOR ELIG MODE ACCTCHEK PHASE02-02-20 08-06-04 35984 B 37 YES NO 31 ANY ACCTNO PHASE08-07-31 09-02-26 21080 B 22 YES NO 31 ANY ACDSTAT1 PHASE03-06-13 - -12344 B 13 YES NO 31 ANY ACDSTAT2 PHASE03-06-13 - -54064 B 55 YES NO 31 ANY ACHCVT PHASE07-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
Re: Getting BIND/LINK date out of load module members
On Wed, 19 May 2010 14:45:13 -0500, Davis, Kriss kpda...@ilstu.edu wrote: You can use the IEWBIND API. A sample can be found in my Cobol-Analyzer www.cbttape.org file+321. Roland I am working on process to monitor/audit load libraries for new/replaced members during a date range. I have a working version that uses AMBLIST with a SYSIN of LISTIDR. I run the REPORT OUTPUT created by this to a disk dataset for a given load library. Then in the next step, I parse the REPORT output looking for the member name and BIND date. If the BIND date is less than 3 days old, I output the member name on the report. The AMBLIST step (unloading all the member data to the report) takes quite awhile for some of our larger LOAD libraries. And of course, outputs a lot more info than I need. I just need the member name and the BIND date. Is there another IBM utility (or a different parameter for AMBLIST) that would unload a LOAD library of its members and dates more efficiently? I only run this once a day, so it is not a big deal that it runs quite a while, but it would help testing new features if I could get the AMBLIST part to run faster. -- 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
Re: Getting BIND/LINK date out of load module members
This is very nice. I find it perplexing, though, that there is apparently no field in a load module PDS that indicates when a member was created and/or last updated. Why is it there for non-load module PDSs but not for load module PDSs? -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 5/19/2010 at 5:50 PM, in message of9089f4f4.460a3c10-on85257728.0081666f-85257728.0082f...@us.ibm.com, Paul Strauss strau...@us.ibm.com wrote: Hi Kriss, Another person replied and suggested using the free PDS tool from the CBTTAPE web site. That should do what you want. I made a copy of SYS1.CMDLIB and ran PDS85 (the name on my system) in batch to get the following report: NAMEALIASOF CREATED SIZE SSI ATTRIBUTES AKJLKL0110/02/08 17832 01119368 RENT, REUS, REFR ARCBDEL 10/02/08 34016 01118183 RENT, REUS ARCRMDS 10/04/12 176K 0158 RENT, REUS CBRUTIL 10/04/12 12112 01110829 RANY, A31, RENT, REUS, REFR HBACK ARCRMDS 10/04/12 176K 0158 RENT, REUS HBACKDS ARCRMDS 10/04/12 176K 0158 RENT, REUS HBDEL ARCBDEL 10/02/08 34016 01118183 RENT, REUS HBDELETEARCBDEL 10/02/08 34016 01118183 RENT, REUS HDELARCRMDS 10/04/12 176K 0158 RENT, REUS HDELETE ARCRMDS 10/04/12 176K 0158 RENT, REUS HMIGARCRMDS 10/04/12 176K 0158 RENT, REUS HMIGRATEARCRMDS 10/04/12 176K 0158 RENT, REUS HRECA ARCRMDS 10/04/12 176K 0158 RENT, REUS HRECALL ARCRMDS 10/04/12 176K 0158 RENT, REUS HRECOV ARCRMDS 10/04/12 176K 0158 RENT, REUS HRECOVERARCRMDS 10/04/12 176K 0158 RENT, REUS IKJLKL01AKJLKL0110/02/08 17832 01119368 RENT, REUS, REFR OAMUTIL CBRUTIL 10/04/12 12112 01110829 RANY, A31, RENT, REUS, REFR I created the above report using the following JCL: //TSO EXEC PGM=IKJEFT01 //STEPLIB DD DSN=SYS4.PDS.V8R5M0.LOAD,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * PDS85 'tsoid.SYS1.CMDLIB' IF : LAST(120) END // For the test above I made a copy of SYS1.CMDLIB in tsoid.SYS1.CMDLIB. This load library had 295 members. The IF : LAST(120) above is telling PDS85 to list out the members (the : says all members in the dataset are included) that were linked over the last 120 days before today (or what ever day it was run). You wanted to run the type of report above going back three days but tsoid.SYS1.CMDLIB did not have any load modules linked over the last 3 days which resulted in the job getting putting out this message 'NO MATCHING ATTRIBUTES WERE FOUND '. That's why I ran it with LAST(120). You should be able to get the product above from web site www.cbttape.org if you don't have it. There are many other keywords for PDS. You could use CHANGED (1/1/10:3/15/10) instead of LAST if you need a range. (Untested) Good Luck. Thank You, Paul Strauss Integrated Technology Delivery, Global Services, IBM L0DB z/OS MVS/Program Products/Security 150 Kettletown Rd. Southbury, CT 06488 (203) 272-2758 strau...@us.ibm.com From: Davis, Kriss kpda...@ilstu.edu To: IBM-MAIN@bama.ua.edu Date: 05/19/2010 06:15 PM Subject:Getting BIND/LINK date out of load module members Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu I am working on process to monitor/audit load libraries for new/replaced members during a date range. I have a working version that uses AMBLIST with a SYSIN of LISTIDR. I run the REPORT OUTPUT created by this to a disk dataset for a given load library. Then in the
Re: Getting BIND/LINK date out of load module members
On Thu, 20 May 2010 01:53:45 -0600 Frank Swarbrick frank.swarbr...@efirstbank.com wrote: :This is very nice. :I find it perplexing, though, that there is apparently no field in a load module PDS that indicates when a member was created and/or last updated. Why is it there for non-load module PDSs but not for load module PDSs? The only thing that is in the PDS directory is what the application creating the member places there. Non-load module PDS do not have dates. ISPF places a date when it creates a member. A JCL created member does not have a date. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
Re: Getting BIND/LINK date out of load module members
Yeah, I remembered that after I wrote the message. But honestly, that is even worse. PDS should have this information. Every other OS I know of at least has last update date, if not both date/time and sometimes also creation date or date/time. -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 5/20/2010 at 2:06 AM, in message k9r9v51r398ujepl1greu66n6urcfh5...@4ax.com, Binyamin Dissen bdis...@dissensoftware.com wrote: On Thu, 20 May 2010 01:53:45 -0600 Frank Swarbrick frank.swarbr...@efirstbank.com wrote: :This is very nice. :I find it perplexing, though, that there is apparently no field in a load module PDS that indicates when a member was created and/or last updated. Why is it there for non-load module PDSs but not for load module PDSs? The only thing that is in the PDS directory is what the application creating the member places there. Non-load module PDS do not have dates. ISPF places a date when it creates a member. A JCL created member does not have a date. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
Re: Getting BIND/LINK date out of load module members
On Thu, 20 May 2010 02:14:33 -0600 Frank Swarbrick frank.swarbr...@efirstbank.com wrote: :Yeah, I remembered that after I wrote the message. But honestly, that is even worse. PDS should have this information. Every other OS I know of at least has last update date, if not both date/time and sometimes also creation date or date/time. Submit a requirement. :On 5/20/2010 at 2:06 AM, in message :k9r9v51r398ujepl1greu66n6urcfh5...@4ax.com, Binyamin Dissen :bdis...@dissensoftware.com wrote: : On Thu, 20 May 2010 01:53:45 -0600 Frank Swarbrick : frank.swarbr...@efirstbank.com wrote: : :This is very nice. : :I find it perplexing, though, that there is apparently no field in a load : module PDS that indicates when a member was created and/or last updated. Why : is it there for non-load module PDSs but not for load module PDSs? : The only thing that is in the PDS directory is what the application creating : the member places there. : Non-load module PDS do not have dates. ISPF places a date when it creates a : member. A JCL created member does not have a date. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
Re: Getting BIND/LINK date out of load module members
Non-load module PDS do not have dates. ISPF places a date when it creates a member. And, an update date. But, using LM services, you can also manipulate all the fields managed by ISPF. - Too busy driving to stop for gas! -- 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
Re: Getting BIND/LINK date out of load module members
Kriss, Paul Strauss was on the right track with his PDS comments. The following IF and ATTRIB subcommands in PDS will do what you want. Download PDS from http://www.cbttape.org/ftp/updates/CBT182.zip. Regards, John K PDS100I PDS86 -- VERSION 8.6.12 APRIL 30, 2010 if : last(3) then(sublist) attrib * short PDS232I NAME ALIASOF CREATED SIZE SSI ATTRIBUTES PDS232I AI9RECAA 10/05/18 184K 01380920 NONE PDS232I PDS PDS8610/05/20 319K PAGE, TEST, RENT, REUS, REFR PDS232I PDSE PDS8610/05/20 319K PAGE, TEST, RENT, REUS, REFR PDS232I PDS86 10/05/20 319K PAGE, TEST, RENT, REUS, REFR PDS118I 2 MEMBERS RMODE24; SIZE IS 502K From: Davis, Kriss kpda...@ilstu.edu To: IBM-MAIN@bama.ua.edu Date: 05/19/2010 02:46 PM Subject:Getting BIND/LINK date out of load module members I am working on process to monitor/audit load libraries for new/replaced members during a date range. I have a working version that uses AMBLIST with a SYSIN of LISTIDR. I run the REPORT OUTPUT created by this to a disk dataset for a given load library. Then in the next step, I parse the REPORT output looking for the member name and BIND date. If the BIND date is less than 3 days old, I output the member name on the report. The AMBLIST step (unloading all the member data to the report) takes quite awhile for some of our larger LOAD libraries. And of course, outputs a lot more info than I need. I just need the member name and the BIND date. Is there another IBM utility (or a different parameter for AMBLIST) that would unload a LOAD library of its members and dates more efficiently? I only run this once a day, so it is not a big deal that it runs quite a while, but it would help testing new features if I could get the AMBLIST part to run faster. Thanks in advance! Kriss Kriss Davis Manager Illinois State University kpda...@ilstu.edu -- 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 -- 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
Re: Getting BIND/LINK date out of load module members
Be careful relying on recent BIND/LINK date for an audit, someone could have copied in a load module that was linked 20 years ago without relinking the program. -- 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
Re: Getting BIND/LINK date out of load module members
snip--- This is very nice. I find it perplexing, though, that there is apparently no field in a load module PDS that indicates when a member was created and/or last updated. Why is it there for non-load module PDSs but not for load module PDSs? unsnip- The presence or absence of a creation date is dependant on the processor that creates the member. For 'source' members, it's usually ISPF that places the CRDATE in the directory entry. For load modules, the actual creation date is present in the IDR data within the member. I can't tell you anything about program objects, since I haven't worked with them. 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
Re: Getting BIND/LINK date out of load module members
On 5/20/2010 at 2:22 AM, in message 29s9v5lniuvtpalf97r7chtu7ogfmj7...@4ax.com, Binyamin Dissen bdis...@dissensoftware.com wrote: On Thu, 20 May 2010 02:14:33 -0600 Frank Swarbrick frank.swarbr...@efirstbank.com wrote: :Yeah, I remembered that after I wrote the message. But honestly, that is even worse. PDS should have this information. Every other OS I know of at least has last update date, if not both date/time and sometimes also creation date or date/time. Submit a requirement. No doubt. I'm just amazed that such a requirement wasn't submited 30 years ago. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 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
Re: Getting BIND/LINK date out of load module members
On 20 May 2010 04:14, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: Yeah, I remembered that after I wrote the message. But honestly, that is even worse. PDS should have this information. Every other OS I know of at least has last update date, if not both date/time and sometimes also creation date or date/time. Every other OS I know doesn't have PDSs. Tony H. -- 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
Re: Getting BIND/LINK date out of load module members
On Thu, 20 May 2010 14:03:48 -0400, Tony Harminc wrote: On 20 May 2010 04:14, Frank Swarbrick wrote: Yeah, I remembered that after I wrote the message. But honestly, that is even worse. PDS should have this information. Every other OS I know of at least has last update date, if not both date/time and sometimes also creation date or date/time. Every other OS I know doesn't have PDSs. I'll regard this as a defect in z/OS. Pedantic. Most of those other OSes have directories (i-nodes; whatever) where such timestamp information is kept. So much the worse for z/OS. And why wasn't this enhancement provided with the advent of PDSE? (Or was it?) Did I hear someone say Requirement? Does the expression snowflake in Hell come to mind? Suppose that STOW were enhanced to save timestamp information in the same format as ISPF (but GMT would be better). What compatibility problems would arise with applications that employ the user info in the directory for other purposes. And even, what unexpected directory space overflows would occur? -- gil -- 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
Re: Getting BIND/LINK date out of load module members
Pedantic. ... GMT would be better ... Since you're being pedantic, wouldn't UTC be better? ;-) Date: Thu, 20 May 2010 13:16:27 -0500 From: paulgboul...@aim.com Subject: Re: Getting BIND/LINK date out of load module members To: IBM-MAIN@bama.ua.edu On Thu, 20 May 2010 14:03:48 -0400, Tony Harminc wrote: On 20 May 2010 04:14, Frank Swarbrick wrote: Yeah, I remembered that after I wrote the message. But honestly, that is even worse. PDS should have this information. Every other OS I know of at least has last update date, if not both date/time and sometimes also creation date or date/time. Every other OS I know doesn't have PDSs. I'll regard this as a defect in z/OS. Pedantic. Most of those other OSes have directories (i-nodes; whatever) where such timestamp information is kept. So much the worse for z/OS. And why wasn't this enhancement provided with the advent of PDSE? (Or was it?) Did I hear someone say Requirement? Does the expression snowflake in Hell come to mind? Suppose that STOW were enhanced to save timestamp information in the same format as ISPF (but GMT would be better). What compatibility problems would arise with applications that employ the user info in the directory for other purposes. And even, what unexpected directory space overflows would occur? -- gil _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2 -- 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
Re: Getting BIND/LINK date out of load module members
On Thu, May 20, 2010 at 7:57 PM, J R jayare...@hotmail.com wrote: Pedantic. ... GMT would be better ... Since you're being pedantic, wouldn't UTC be better? ;-) Date: Thu, 20 May 2010 13:16:27 -0500 From: paulgboul...@aim.com Subject: Re: Getting BIND/LINK date out of load module members To: IBM-MAIN@bama.ua.edu On Thu, 20 May 2010 14:03:48 -0400, Tony Harminc wrote: On 20 May 2010 04:14, Frank Swarbrick wrote: Yeah, I remembered that after I wrote the message. But honestly, that is even worse. PDS should have this information. Every other OS I know of at least has last update date, if not both date/time and sometimes also creation date or date/time. Every other OS I know doesn't have PDSs. I'll regard this as a defect in z/OS. Pedantic. Most of those other OSes have directories (i-nodes; whatever) where such timestamp information is kept. other platforms (windows, unix) have utilities (touch and the like) that can update the external directory date and time stamp very easily. This is used quite often in the build process for force unmodified code to be recompiled or relinked. In this case, the external timestamp does not reflect the actual link timestamp. It would seem to be counter to the OPs requirement. Also, in the case of composite links any external timestamp reflects the status of the overall module and not necessarily any particular component. This is probably not relevant to the OPs requirements. Externally maintained date and time stamps of any nature fall prey to these type of utilities. So much the worse for z/OS. And why wasn't this enhancement provided with the advent of PDSE? (Or was it?) Did I hear someone say Requirement? Does the expression snowflake in Hell come to mind? Suppose that STOW were enhanced to save timestamp information in the same format as ISPF (but GMT would be better). What compatibility problems would arise with applications that employ the user info in the directory for other purposes. And even, what unexpected directory space overflows would occur? -- gil _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2 -- 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 -- 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
Re: Getting BIND/LINK date out of load module members
snip- I'll regard this as a defect in z/OS. Pedantic. Most of those other OSes have directories (i-nodes; whatever) where such timestamp information is kept. So much the worse for z/OS. And why wasn't this enhancement provided with the advent of PDSE? (Or was it?) Did I hear someone say Requirement? Does the expression snowflake in Hell come to mind? Suppose that STOW were enhanced to save timestamp information in the same format as ISPF (but GMT would be better). What compatibility problems would arise with applications that employ the user info in the directory for other purposes. And even, what unexpected directory space overflows would occur? -unsnip--- I don't regard it as a defect at all. The Operating System doesn't need this date information to function properly; why clutter things up with info that's not needed? Most applications also don't need it; it's only a convenience for us humans. And I wouldn't like to try to rewrite Program Fetch, considering all the formats of data that are already in the directory for a load module. 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
Re: Getting BIND/LINK date out of load module members
On Thu, 20 May 2010 16:38:49 -0500, Rick Fochtman wrote: [...]. Most of those other OSes have directories (i-nodes; whatever) where such timestamp information is kept. I don't regard it as a defect at all. The Operating System doesn't need this date information to function properly; why clutter things up with info that's not needed? Most applications also don't need it; it's only a convenience for us humans. And until you explained this, I had believed that the Operating System as a whole existed as a convenience for us humans; not, as you appear to believe, merely to satisfy its own needs. As for clutter, better to do such things consistently, in DFSMS for example, rather than haphazardly in ISPF, NFS server, and whatever other services feel obliged to simulate ISPF's facility. -- gil -- 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
Re: Getting BIND/LINK date out of load module members
You can do this with the shareware version of PDS tools assuming you are talking about a standard PDS load library. Although no way to limit by date range. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Davis, Kriss Sent: Wednesday, May 19, 2010 3:45 PM To: IBM-MAIN@bama.ua.edu Subject: Getting BIND/LINK date out of load module members I am working on process to monitor/audit load libraries for new/replaced members during a date range. I have a working version that uses AMBLIST with a SYSIN of LISTIDR. I run the REPORT OUTPUT created by this to a disk dataset for a given load library. Then in the next step, I parse the REPORT output looking for the member name and BIND date. If the BIND date is less than 3 days old, I output the member name on the report. The AMBLIST step (unloading all the member data to the report) takes quite awhile for some of our larger LOAD libraries. And of course, outputs a lot more info than I need. I just need the member name and the BIND date. Is there another IBM utility (or a different parameter for AMBLIST) that would unload a LOAD library of its members and dates more efficiently? I only run this once a day, so it is not a big deal that it runs quite a while, but it would help testing new features if I could get the AMBLIST part to run faster. Thanks in advance! This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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
Re: Getting BIND/LINK date out of load module members
Hi Kriss, Another person replied and suggested using the free PDS tool from the CBTTAPE web site. That should do what you want. I made a copy of SYS1.CMDLIB and ran PDS85 (the name on my system) in batch to get the following report: NAMEALIASOF CREATED SIZE SSI ATTRIBUTES AKJLKL0110/02/08 17832 01119368 RENT, REUS, REFR ARCBDEL 10/02/08 34016 01118183 RENT, REUS ARCRMDS 10/04/12 176K 0158 RENT, REUS CBRUTIL 10/04/12 12112 01110829 RANY, A31, RENT, REUS, REFR HBACK ARCRMDS 10/04/12 176K 0158 RENT, REUS HBACKDS ARCRMDS 10/04/12 176K 0158 RENT, REUS HBDEL ARCBDEL 10/02/08 34016 01118183 RENT, REUS HBDELETEARCBDEL 10/02/08 34016 01118183 RENT, REUS HDELARCRMDS 10/04/12 176K 0158 RENT, REUS HDELETE ARCRMDS 10/04/12 176K 0158 RENT, REUS HMIGARCRMDS 10/04/12 176K 0158 RENT, REUS HMIGRATEARCRMDS 10/04/12 176K 0158 RENT, REUS HRECA ARCRMDS 10/04/12 176K 0158 RENT, REUS HRECALL ARCRMDS 10/04/12 176K 0158 RENT, REUS HRECOV ARCRMDS 10/04/12 176K 0158 RENT, REUS HRECOVERARCRMDS 10/04/12 176K 0158 RENT, REUS IKJLKL01AKJLKL0110/02/08 17832 01119368 RENT, REUS, REFR OAMUTIL CBRUTIL 10/04/12 12112 01110829 RANY, A31, RENT, REUS, REFR I created the above report using the following JCL: //TSO EXEC PGM=IKJEFT01 //STEPLIB DD DSN=SYS4.PDS.V8R5M0.LOAD,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * PDS85 'tsoid.SYS1.CMDLIB' IF : LAST(120) END // For the test above I made a copy of SYS1.CMDLIB in tsoid.SYS1.CMDLIB. This load library had 295 members. The IF : LAST(120) above is telling PDS85 to list out the members (the : says all members in the dataset are included) that were linked over the last 120 days before today (or what ever day it was run). You wanted to run the type of report above going back three days but tsoid.SYS1.CMDLIB did not have any load modules linked over the last 3 days which resulted in the job getting putting out this message 'NO MATCHING ATTRIBUTES WERE FOUND '. That's why I ran it with LAST(120). You should be able to get the product above from web site www.cbttape.org if you don't have it. There are many other keywords for PDS. You could use CHANGED (1/1/10:3/15/10) instead of LAST if you need a range. (Untested) Good Luck. Thank You, Paul Strauss Integrated Technology Delivery, Global Services, IBM L0DB z/OS MVS/Program Products/Security 150 Kettletown Rd. Southbury, CT 06488 (203) 272-2758 strau...@us.ibm.com From: Davis, Kriss kpda...@ilstu.edu To: IBM-MAIN@bama.ua.edu Date: 05/19/2010 06:15 PM Subject:Getting BIND/LINK date out of load module members Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu I am working on process to monitor/audit load libraries for new/replaced members during a date range. I have a working version that uses AMBLIST with a SYSIN of LISTIDR. I run the REPORT OUTPUT created by this to a disk dataset for a given load library. Then in the next step, I parse the REPORT output looking for the member name and BIND date. If the BIND date is less than 3 days old, I output the member name on the report. The AMBLIST step (unloading all the member data to the report) takes quite awhile for some of our larger LOAD libraries. And of course, outputs a lot more info than I need. I just need the member name and the BIND date. Is there another IBM utility (or a different parameter for AMBLIST) that would unload a LOAD library of its members and dates more efficiently? I only run this once a day, so it is not a big deal that it runs quite a while, but it would help testing
